Simplest Transaction Flow - Ping Pong

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

## Tramlines view of the ping-pong between components


This demonstrates the problem that at it's core FireFly is there to solve. The internal plumbing complexity of just a very simple set of Enterprise blockchain / multi-party system interactions.

- Party A: Establish existence of a digital asset
- Nothing more than some binary data (an image, a document, a specification etc. etc.)
- Party A: Broadcast some information about that asset to everyone, using blockchain to record, sequence and propagate
- So people can find it, or part of a more sophisticated workflow
- Party B: Request the actual data - with evidence of that request tied to the blockchain
- Including some *private* data that's sent to the Party A, reliably off-chain
- Party A: Authorize the request, and send the data *privately* to Party B
- In this example there's no blockchain involved in this step

This is the kind of thing that enterprise projects have been solving ground-up since the dawn of enterprise blockchain, and the level of engineering required that is completely detached from business value, is very high.

The "tramlines" view shows how FireFly's pluggable model makes the job of the developer really simple:
- A few simple API calls from a modern web app
- Event triggered execution of application logic

This is deliberately a simple flow, and all kinds of additional layers might well layer on (and fit within the FireFly model):
- NFTs to track ownership etc. related to the digital asset
- Tokenized rewards/payments integrated with the authorization of the transfer of data
- Proof of deterministic execution of the logic to perform the authorization (on-chain, TEEs, ZKPs)
- Human workflow, that is of course completely non-deterministic
- Multiple additional process steps, deterministic or not
- Inclusion of multiple additional parties (maybe it's a request-for-tender, submit-tender flow for example)
- etc. etc.

@jimthematrix will be publishing a separate issue that discusses Delivery vs. Payment flows, which are a particularly interesting category of scenarios where FireFly APIs (in Generation 1) already add some simplification for users, and we expect to extend those (through the evolution of Generation 2).