CardinalityOne not correct for partially-ordered times

The state machine powering the `CardinalityOne` operator currently assumes totally ordered input timestamps, s.t. when processed in time order (i.e. in the order that `consolidate` will reveal them), all keys end up in the correct state.

In fact, the current implementation is a bit stronger, in that it should still produce correct results on bitemporal inputs, as long as event times increase monotonically per key. This is due to an [additional sort by event time after consolidation](https://github.com/comnik/declarative-dataflow/blob/master/src/operators/mod.rs#L56).
For [general partially-ordered inputs](https://github.com/comnik/declarative-dataflow/blob/master/tests/cardinality_one.rs#L362) this is not safe any longer.

A solution might be to re-implement `CardinalityOne` as a special kind of `arrange`. This way we could use the trace handle to lookup the correct last value as of the input time, without having to maintain two traces per attribute.

The existing implementation should get rid of the additional sort and live on as `CardinalityOneTotal`, or something like that.

Lies die aktuelle CardinalityOne-Implementierung und die zusätzliche Sortierung in src/operators/mod.rs um Zeile 56. Führe den Fall mit teilweise geordneten Eingaben in tests/cardinality_one.rs um Zeile 362 aus, um die inkorrekten Zustandsübergänge zu verstehen. Als erledigt gilt die Aufgabe, wenn CardinalityOne allgemeine teilweise geordnete Eingaben korrekt verarbeitet und das bestehende Verhalten für totale Ordnungen wie vorgeschlagen getrennt ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.