Replace pre-processor → PUT → post-processor with configurable workflow

[nevali]

Currently a graph update triggers a fixed workflow of:

• Invoke any registered pre-processors, if any
• Perform a SPARQL PUT operation
• Invoke any registered post-processors, if any

Both the pre- and post-processors use the same function signature, which is an int-returning callback accepting a twine_graph and module-defined void * data pointer.

To allow for more flexible workflows, this could be replaced by a configurable sequence of processors to invoke in a defined order. For compatibility:

• Special identifiers would be used to indicate 'all pre-processors' (preprocess) and 'all post-processors' (postprocess)
• The SPARQL PUT operation would be encapsulated into a built-in processor (sparql-put)
• If no workflow is configured, the default would be preprocess; sparql-put; postprocess

All registered processors can be tracked in a flat list in a common namespace, with an automatic pre: and post: prefix applied to modules registered using the legacy pre- and post-processor registration APIs. Modules would be expected to migrate away from registering pre- and post-processors specifically once deployed applications no longer make use of the preprocess and postprocess special-case workflow entries, with the specific point at which they're invoked dictated exclusively by the configured workflow. In the interim, they would be free to register a module using both the legacy registration APIs as well as the new unified processor registration API (for example, a pre-processor named example would registered as both pre:example and example—the former being invoked by the preprocess special identifiers, and example available for direct invocation by name).

[nevali]

There will need to be a sparql-get module defined for populating the old model within the graph object.