Task #1793: cleanup of integration loop
implement force calculation via ForceProviders containing collections of IForceProvider
In order to simplify high-level code (#1793), implement hardware- and locality-aware task parallelism, and expose functionality to APIs (gmxapi, #2229) we need a more flexible framework for code that calculates forces. That is likely to include all such code implementing the IForceProvider interface, and for ForceProviders to arrange for them to be called. For now, that will also still involve t_forcerec. In future, it is hoped the collaboration between the ForceProviders, the available hardware, the state of any auto-tuners, user input, and the integration schedule (#1137) will be able to implement a highly flexible, modular, yet optimizable, run-time framework to replace the hard-coded execution schedules in e.g. do_md() and do_force() (and sub-functions).
This will take a while and the exact endpoint is rather unclear!
Move responsibility for bonded threading decomposition
This is an aspect of force calculation, not of the topology needed for
that force calculation.
Removed use of assert no longer needed now that the responsiblity has
Also updated some use of struct keyword.
Allow extensible MDModules and forceProviders.
supports gmxapi milestone 6, described at #2585.
MDModules::Impl gets a std::vector for (shared) ownership of objects
providing the IMDModule interface. An add() method is added to the
MDModules public member functions, but the binding protocols are
separated into separate issues to allow minimal changes and varying
dependencies on other pending changes.