Spec out transaction ingestion logic within the context of the OVM

[karlfloersch]

Is your feature request related to a problem? Please describe.
In our previous aggregator design the transaction ingestion logic looked a lot like the StateManager logic. However, with our recent OVM architecture this becomes less clear because it's harder to "fudge" the StateManger in this way.

In particular the way we were modifying the StateManager is before we were assuming inclusion of whatever StateUpdate that executeTransaction(...) produced. Now, because the OVM will automate guarding if we do it correctly, it's less clear how to do this.

Describe the solution you'd like
There are two main approaches for how to solve this problem:

1. Aggregator ingests transactions as proofs that are applied to the OVM, and then inspects decisions made on the OVM to determine if that transaction should be applied in the next block.
2. Aggregator runs custom logic which is special built for handling transaction authentication that in it's simplest form is a rangeDB with all of the currently authenticated owners of a particular range. If a message + signature is received by an owner the message is queued for the next block.

The 2nd solution is much less general purpose, but it's quite straightforward to implement especially under the assumption that only one user is able to queue up a new SU to be included. In the long term transaction inclusion will have to take into consideration things like transaction fees, which will further complicate things. The unknown unknowns are probably the best argument for approach (2).