Remove boilerplate for plugin instantiation

[eirrgang]

The Builder stuff in the sample_restraint doesn't belong there. It needs to be removed to a gmxapi feature (provided headers) and greatly improved. It will become a configurable Director to construct the part of the Session corresponding to the plugin. Client code will configure it with available inputs, outputs, and parameters with pybind-like syntax. Relates to #44 but does not need to wait for resolution to that issue to simplify sample_restraint. Relates to #47

The long term solution to all things surrounding the plugin environment is basically this:

• plugin code uses Session resources for input, output, supporting operations, and state data
• plugin developer just writes functions (not classes) and defines all of the input, output, and state through descriptive templating mechanisms (inspired by pybind and boost)

In addition to (hopefully) simplifying the development environment a bit, we can simultaneously address aspects of other issues, like #36, #40, #69.

We can implement this one part at a time, starting with state data. By storing state data in an object received from the Session, we can eliminate private data members and automatically checkpoint everything about a plugin. There are several optimizations that will be easier to make, but one potential performance challenge is the dichotomy of type safety and custom data structures.

We can consider less type safety, run-time type information, or building more templated code in the plugin.

Regardless, I think the plugin developer interface is the same, so hopefully if we choose wrong we only have to ask developers to update headers and recompile.

[eirrgang]

The resources a plugin receives will either have to be templated on the plugin or have a whole lot of casting and/or run-time type stuff, I think, so I'm going to first explore templating. The early result will look like I am replacing the class that the developer previously defined with a class I cobble together with templating, I expect.

• developer defines a struct to hold their state. The types it can hold are limited to types our API knows how to serialize.
• developer writes the functions they want called. State variables are instead accessed through a member (with the struct type) of a (templated) resources argument passed in.
• developer expresses a template to connect the pieces.
• developer calls functions on the resulting object for each member of the state data structure to declare their keyword name, type, behavior, and initialization.

I don't know how to check for uninitialized struct members in this case. We might be able to build up a constructor call that would only compile if we are able to use the automatic POD aggregate constructor.

It isn't worth conjecturing further until I experiment a bit.