Reorganize Context and WorkSpec hierarchy

[eirrgang]

Though not part of the schema itself, we can include discussion of how API interaction with the specification could/should work. E.g. elements should be views into the spec object rather than independent objects; the spec object should contain additional members to maintain contact with the (chain of) Contexts associated with the work spec (and should itself maybe just be a view into the Context, with spec objects requiring a Context to exist at all)

• gmx Python module has one Context class (not a base class and derived classes) with composed/mix-in functionality if necessary. gmx.context.Context can have a supporting C++ extension class, but this is distinct from the library Context. Unify gmx.context #89
• If not already present, gmx Python module has a default Context singleton created for a work spec and becomes the manager for proxy interfaces Implicit context stored in Python module variable #90
• WorkSpec object is a handle to a resource managed by the Context (no longer directly modifiable). Thinner WorkSpec #91
• WorkElements are views into the WorkSpec resource. Thinner WorkElements #92
• libgromacs gets a C++ Context instance to manage MPI communicator and external object binding before any gmx objects are created. C++ Context for libgromacs #93
• specified data access and operations performed with the Python proxy objects is automatically directed through the local context to the library context. Add proxy access to data graph through WorkElement handles #94
• somewhere in here, we need to figure out what elements look like in C++ and how to generate a Python WorkElement from C++. The implication from the above tasks is that this happens through the Context interface. Formalize the external WorkElement interface for plugins #43