Plugin Architecture

> See #4 for info on why this is in Git

## FireFly Three Layered Plugin Architecture

In #6 the extensible nature of the FireFly node is described, with separate pluggable runtimes orchestrated into a common API for developers.

Here the mechanic of that pluggability for developers of new connectors is explained:


This architecture is designed to provide separations of concerns to account for:
- Differences in code language for the low-level connection to a backend (Java for Corda for example)
- Differences in transports, particularly for delivery of events:
- Between FireFly Core and the Connector
- Different transports other than HTTPS/WebSockets (GRPC etc.), and different wire protocols (socket.io, etc.)
- Between the Connector and the underlying Infrastructure Runtime
- Often this is heavy lifting engineering within the connector
- Differences in High Availability (HA) / Scale architectures
- Between FireFly Core, and the Connector
- Often for event management, and active/passive connector runtime is sufficient
- Between the Connector and the Infrastructure Runtime
- The infrastructure runtimes have all kinds of variation here... think of the potential landscape here from PostreSQL through Besu/Fabric/Corda, to Hyperledger Avalon and even Main-net ethereum