Design pipeling for the processor

[dzhelezov]

This is a follow-up issue on #61

At the moment all the processing is done in a single step: Raw Event -> Call a mapping function. We can design a more robust processing system, roughly working as follows:

• Figure out what events to fetch next (including e.g. wildcard filtering Arbitrary filters for fetching events from the indexers #105)
• For each event in the queue figure out processing steps as defined in the manifest file. For example, the processing steps may e.g. look as follows:
  • Transform event data into a type-safe interface as defined in the schema
  • Decode fields as necessary (as e.g. Decode extrinsic args for sub call #6 or EVM)
  • Transform as defined in the mapping (with type-safe parameters)

The processing steps should be fully open-ended and implement a common interface. In particular, it should be possible to import a public pipelining step as a self-contained npm library and simply include it in the manifest file.

[dzhelezov]

Outlined in #125 (Virtual Events)