Forcefield roundtrip when specifying monty dict

[esoteric-ephemera]

Closes #1460:

• Allows for specifying either:
  1. force_field_name as a monty-style dict
  2. calculator_meta as a dot-separated import str (preferred)
  3. calculator_meta as a monty-style dict
• Regression test for roundript, thanks to @gpetretto's example
• Updated docs accordingly

For the next minor release (v0.2.0), the forcefield interface could use some significant simplification. This will just serve as a patch

[gpetretto]

Hi @esoteric-ephemera, thanks for implementing this fix.

I think the solution may be fine, but I wonder if the fact of transforming the dict into an ad hoc string would not increase the likelyhood of ending up with backward incompatible updates later on. It seems that this string serialization may complicate any different use of dict or str values for calculator_meta.
One concern that I have is that future changes may lead to serialized jobs in a DB that may not be deserialized.

However, if you expect that v0.2.0 will introduce breaking changes anyway, it may not be worth to focus on potential future issues here.

[esoteric-ephemera]

Thanks @gpetretto and good point. I added a bit more logic to the deserialization that should handle cases when force_field_name was stored as a dict in JSON. Also added a test for this

If you have some legacy docs where you could test that this correctly handles legacy docs, would appreciate it!

[gpetretto]

Thanks for this update! I have tested and it seems to work fine deserializing this type of makers.

I should mention that in my previous message I was also refferring to potentially future incompatibilities. Serializing the dictionary with calculator_meta=".".join(calculator_meta[k] for k in ("@module", "@callable")), if another kind of str or dict may need to be passed to calculator_meta in the future it may be difficult to preserve backward compatibility.