Support for MergeAppend

[Fokko]

The so-called fast-appends are added in #349

It would be good to also consider adding merge-commits.

With the fast-append, a new manifest is written out and added to the manifest-list as mentioned in the spec. As the name suggests, this is the fastest way of appending new data, minimizing the chance of conflicts. Also, it works pretty well in the case of a commit, since only the manifest has to be rewritten in case of a conflict. The biggest drawback is that you create many manifests adding overhead in the long run (more calls to the object store than needed).

The merge-commit takes an existing manifest, adds the new entries to it, and replaces the old manifest in the manifest-list.

Having too few manifests is not good because it will lead to limited parallelization, but too many will add much overhead in terms of networking and parsing. The thresholds can be configured through configuration, and have some reasonable defaults:

The goal of this issue is to add MergeAppendAction next to FastAppendAction. This is not a trivial task since there are some caveats:

• Each manifest is bound to a certain partition strategy, meaning that the partition-spec-id is stored in the Avro header, and they should be all the same.
• When rewriting the existing manifests, the ADDED status must be changed to EXISTING, and the sequence numbers must be tracked correctly.

[ZENOTME]

I'm working on the merge append. And I find that the manifest writer needs to be refined first in #738 so that the code can be more clean.