Customizable slot merge strategies.

Previously the only supported merge strategy was to compare for equality
and declare a conflict if any states are unequal. Although that remains
the default, we can now provide a custom merge strategy to allow for
different use cases, like a slot containing a set that we only ever add
to, whose merge strategy is to combine all of the sets together using
the union operation.
Allow slots to customize their forking behavior.

When storing mutable objects inside a data slot, the default behavior of
the state system is broken because they all end up sharing the same
object and thus a transaction is not isolated as expected.

This new mechanism allows a slot to be configured with forking behavior
so that child states can operate on clone objects rather than the original
object. For example, a slot containing a mutable set would presumably
have a fork implementation that copies it into a new set.

The copy happens only when the slot is read in the context of a child
scope, so this adds no significant extra cost to transactions that do not
access slots with forking behavior.

The downside of this facility is the slot's value doesn't actually change
and so the "position" mechanism is defeated. Callers which *do* need to
keep track of positions should use an individual slot for each value
so that each can be updated with its position as needed.