Feature request: Make MultiStreamAppendAsync take respect event order across streams

[yreynhout]

Right now, the multi-stream append method takes a very stream-centric approach to appending to streams instead of an event-centric one. One simply can't record the sequence of events in the order they took place, regardless of the stream they happen to land into. This limitation effectively eliminates a lot of useful scenarios such as transacting over multiple deciders or deciders in combination with workflows. Such scenarios are big cost savers in because they cut down on the number of processes, subscriptions, and operational complexity. The order in which events are observed on the other side is another argument to be able to record across streams with full fidelity of the recording order.

One should be able to record batches such as (S1, [ E1, E2 ]),(S2, [ E3 ]),(S1, [ E4, E5 ]),(S3, [ E6 ]) IN ORDER. While from a transactional point of view, it won't really matter in that all pre-conditions will still have to be met and atomicity must be respected, today, with the current API, this would manifest itself as (S1, [ E1, E2, E4, E5 ]),(S2, [ E3 ]),(S3, [ E6 ]) which, honestly, is not the same story being told, because the order in which you tell facts IS INFORMATION by itself. One could argue, well if order matters, put it all in one stream, but I'm sure you'll agree with me that there may be other heuristics at play when it comes to stream design that would make that a sub-optimal choice that would have other consequences.