Pick a specific added element rather than randomizing after generation.
Choose the origin replica from the added field rather than randomly.
Add a vclock to the model for parent_clock replacement

When the map performs an update to a field,it replaces the embedded
crdt's clock with it's own. It does this because context operations
on fields in a map take the maps context.

This leads to a neat semantic change: when you remove a set or flag,
and then re-add it by updating, the new entry gets the Maps clock,
which means it has seen all the elements that were removed by removing
the field. This leads to a defacto reset-remove semantic for sets and
flags. Assuming time goes forward the same is true for lwwreg. Only
counters have a strange semantic on field remove | re-add now.

Note: just _adding_ the field does not lead to this behaviour, only
and update causes the clock to be replaced. Otherwise an `add` to a
field that is present would be short hand for "remove, then add"
(which maybe it should be??)
Increment the clock by the count,not by one
Merge pull request #88 from basho/bugfix/rdb/common-clock-model

Add the `parent_clock` call on update to the Model for map_eqc