Generalize connector functionality

[SanderMertens]

Now that there are a couple of corto connectors, idioms emerge as to how they are best written. These must be captures in a reusable component that would ease writing new, high quality connectors.

This component shall be called a replicator. A replicator should at least provide the following functionality:

• Forward declare, define, update and delete events
• Take into account ownership (don't forward objects for which process is not the owner on same medium)
• Forward method calls to appropriate owner
• Selection of which objects are replicated (out)
• Mount point where synchronized objects are being stored (in)

Additionally it can provide:

• Support for threading
• Support for polling vs. event based for corto store
• Support for polling vs. event based for medium
• Control polling frequencies
• Control tolerance (how long can a medium be disconnected)
• Support for suspending objects (delegate storing object to medium)
• Support for resuming objects (restore object from medium into store, requires hook in resolve function)
• Automate dependency serialization (note that for cross-replicator dependencies to work, dependency admin must be a singleton)

[SanderMertens]

The following features are implemented for replicators (from the description):

• Forward declare, define, update and delete events
• Take into account ownership (don't forward objects for which process is not the owner on same medium)
• Forward method calls to appropriate owner [BETA]
• Selection of which objects are replicated (out) [BETA]
• Mount point where synchronized objects are being stored (in)

Subsequent issues will address the remaining features.