Rework Transaction/Batching handling

[uweschaefer]

There is a problem in transaction handling, that on reconnect, a subscription thread might be changed, so that an incomplete transaction (from a factus projection) can casue an inconsistent perception of a current factStreamPosition.
One way to solve this is to commit incomplete transactions on close of a subscription, so that the factStreamPosition gets back to consistent. see #1817

However, The transaction handling part is unnecessary complex and we feel like it leaves too many options for misconfiguration so that we'd suggest to solve this problem in a different way, that will hopefully make things much easier to implement as well as more intutive to understand:

• on subscription, define a max latency and a max size of batch (always, not only with transactions)
• deprecate onNext(Fact f) on FactObserver and replace it with onNext(List factBatch)
  ** note that we need to have a default here to keep the compatibility
• factBatch will be applied within a transaction/batch, if there is an error - everything will always be rolled back
• simplify ProjectionLenses accrodingly
• the ReconnectingSubscription has an always consistent view regadring facts applied and factStreamPositions compared to the projection.

The hope is, that most of this can be changed without the necessity to touch application-level code.

[BernhardBln]

Please check if that was maybe caused by #2316

[uweschaefer]

no it wasn't

[uweschaefer]

Decided to add BatchingFactObserver to prevent possible infinite loop in default methods

[uweschaefer]

this is done by the major rewrite that is part of 0.8