Refactored data storage in default implementation

Previous implementation (holding box values in the Revision's "big"
map) lead to strong retention of any keys within value objects. For
example, with a case class Person(name: Box[String]), when that Person
is stored as a value in the map (e.g. in a Box[Person]) this creates a
strong reference to the name Box, preventing it from being collected,
at least until the Box[Person] is collected. But in any non-trivial
system it is likely that there will be enough references to cause a
memory leak as values retain other Boxes.
To address this, we need to make sure that we retain a value of a Box
for only as long as both the Box itself is reachable, and at least one
Revision is reachable where Box had the value in question. This results
in a slightly complicated structure, where we use a WeakHashMap in the
Box itself to store previous values of that Box, referenced by keys of
type Change. We then use a map in Revision from each Box to the Change
that was most recent in that Revision. This creates a strong reference
from the Revision to exactly those Changes that are needed to retrieve
data from Boxes to reconstruct that Revision. When no reachable
Revision references a Change, that data is then lost from the weak hash
map in the Box, removing the memory leak. Similarly, if a Box is not
reachable, it will be GCed, and the values in its weak hash map will no
longer be referenced through that Box. Note that the Changes for those
values might still be in a Revision, but since the Box itself is no
longer reachable, nothing can actually look up the Box in the Revision,
and so the "missing" data is invisible externally. The mappings from
the GCed Box will be removed from future Revision maps via pruning.
This should also address a related problem with the old system, where
pruning might lag behind GC, or indeed slow it down - when the
Revisions' "big" maps stored actual value data, they would retain that
data until the Box was pruned from a new Revision, and the old Revision
was itself GCed. However only one "jump" could be pruned at a time, and
further pruning of (for example) keys that were referenced from those
pruned values could not occur until all older revisions were GCed. Now
the revision maps only retain data they actually need, via Changes, and
so GC should not be artificially restricted.
In general, this structure seems to meet all requirements, but to be
honest the performance in terms of memory and speed may well be
awful... Further optimisations are no doubt possible ;)

Added a simple demo that checks that GC of a "Loopy" case class that
can create Box->Value->Box... cycles in data. With previous default
implementation, these were never GCed (while the same case class WOULD
be GCed if it contained no cycles), now cycles are collected as
expected.