Change the way we handle removes with a context

As @lenary pointed out, in some situations a field update concurrent with a field remove, could result in the update losing.

We applied removes to the context. But removes of a nested map field, or nested set element are also a Add for the containing field. If the local replica has since modified the field, and then removed it, the clock for the Map will dominate the dot for the field in the context. The field remove wins over the concurrent field update.

By making sure that all field updates (even removes) end up on the Add list of operations this PR fixes that bug.

There is an eunit test that fails without this fix, and passes with it, in riak_kv_crdt.

Another change is that the remove ops are applied to the context, and the add operations are applied to the local merged state and only then are the context and local state merged. Previously the updated context was merged with the local state before the add operations were performed.