Clear distinction of Python and C++ domains in plugin environment

[eirrgang]

The symptom here is that when operations are subscribed to other operations, there is explicit passing of Python objects in the Builder classes that are currently embedded in the plugin implementation boilerplate.

We have kind of a muddled process to transition back and forth between Python and C++ in plugin instantiation. We need to provide an all-C++ wrapper for the plugin code and let the Session implementation handle the transitions between Python and C++. However, we want the developer to express the Python keyword parameter names, help text, and access type in a single environment, so we can figure out how to carve that up. The hidden story here is probably that the gmxapi framework for context and session needs to be beefed up.

The expectation is that interaction between operations will be mediated by the Session implementation via the Session Resources object. It is still unclear how we consider the difference between high-level data flow and more tightly bound interactions. I think that maybe we should clearly specify an API protocol that allows compatible operations to fuse themselves during Session building. The template code that wraps a restraint plugin now adapts a generic gmxapi interface to a GROMACS interface. This could be provided by a GROMACS public header, and if the Directors detect this interface, they can collaborate to merge the graph nodes. Data flow involving operations that aren't fusable can cause the directors to re-divide the node a bit, but I think we can assume that the libgromacs Context can provide fusing for restraint operations and for the logical operations processing simulation stop signals. The fused node (cluster) has the combined set of input and output ports that aren't fully subscribed internally. The fused node should probably implement the Context-to-Context interface for the chain-of-responsibility in #75 and #65 and another issue I can't find right now.

Somewhere in here is a set of tasks to replace the Builder boilerplate with the director scheme described elsewhere. #47, #62, #44

Also related to #48 #32