Add skeleton prototype

[lilyminium]

This is a draft PR to prototype some functionality where the higher-level overview is in these slides: https://docs.google.com/presentation/d/1pbhua2YHi7Xohw_t2EEndB7_Y4BHWudJ8llPYKxvDTQ/edit?slide=id.g3bbe24ca41d_0_8#slide=id.g3bbe24ca41d_0_8

Here are the broad modules:

• configs -- specifying how to execute particular protocols, and what simulations/settings should be run for different properties.

  • At some point IMO there should be an overall "TrainingConfig" or even "OverallWorkflowConfig" with parameters like store_last_frame_of_accepted_step (for storing boxes from the last accepted iteration), and possibly stuff like delete_working_data (whether to delete simulations from previous iterations to save disk space). Perhaps also settings currently in the protocol configs, such as the path to the coordinate store in the equilibration config, and whether to save the lowest energy of three replicates, etc., should be in this overall config.
  • Other configs for things like servers

• ops -- for calculating properties differentiably. Only Osmotic coefficient is filled out at the moment, but the density and enthalpy should be simpler and straightforward. Potentially the osmotic coefficient should actually just be the osmotic pressure and the coefficient part can occur in compute_property. We need some way to pass the correct force group into this op -- poassibly it's most straightforward to change the OsmoticCoefficient.force_name to a OsmoticCoefficient.force_group.

• protocols -- for executing protocols. None of this is filled out, except for creating the OpenMM system.

• workflow -- a prototyped workflow for getting from dataset + force field, to predicted properties and closure function.

• server/client -- draft Client with the basic functionality we'd need. It's a very thin wrapper over dask at the moment, but I have checked that all current functionality is easily extensible to Ray.

Many bad choices were made here, including the naming of particular classes, and especially the construction of the many intermediate classes that basically only exist so we can easily track what's going on (e.g. _Task, BoxKey, EntrySimulation). While I think the general separation of configs vs protocols vs properties vs ops would be helpful to have, I don't think this PR is structured super well. I've opened it because working through it was helpful for me to think through what would really be needed to get from dataset + force field --> computed properties.

[lilyminium]

Maybe we should cut out the middleman here and just specify the force group (int).

[lilyminium]

hack to support ion specifications (see #11)