Optimize large transactions using an out-of-order TLog

One of the main problems with large transactions is that all of the mutations have to be written at the same version, which can then cause a huge latency spike for other transactions trying to commit at the same time.

If we could write the mutations from a large transaction incrementally over a period of time before making them visible at a later version, we should be able to significantly improve the performance of large transactions, and also increase the transaction size limit.

The basic idea to make this possible, is that we could tag mutations in a tlog with a special tag that is not delivered to any storage server, and return back to the user the offset into the disk queue where those mutations were written. A future commit could them write a mutation which references the mutations with the special tag written at that offset.

The main challenge with this design is that the mutations with the special tag cannot have any storage tags on them, because it is possible for data movement to move the keyrange between the first commit and the second commit which references the first commit. This means this feature would be dependent on the alternative suggested in https://github.com/apple/foundationdb/issues/2510 where we only add the log router tags when committing to the primary tlogs. In this case, the storage tags would only be added later on the log routers and therefore this should not be a problem.

No files, tests, or entry points are named. Start by reviewing the proposed out-of-order TLog design and the alternative in issue #2510; a complete design should define how tagged mutations, disk-queue offsets, commits, and log-router tags interact without storage tags during data movement.

Written by the indexing model from the issue text.