Add the notion of a pending union and a redirect.

Basic idea:

Unions are associative. Given a large number of unions (e.g. when
building up an intmap by a series of inserts) we are effectively
building up a large union x1 | x2 | ... | xn. Wouldn't it be nice
if we could choose the evaluation order to be super fast?

This is what we have intmap_builder for. It maintains a nice stack
of intmaps and attempts to merge them in a more efficient way than
just one at a time.

But wouldn't it be nice if we didn't have to use a different API
and it was just taken care of for us automatically?

Well it turns out that in a lot of cases we can! Because union
operations are destructive and we use reference counting we can tell
which subexpressions we care about the value of and which we are able
to just screw around with and break up as we wish. So we do that.

We do this by introducing a PENDING_UNION type, which is an intmap_builder
in disguise as an intmap. When we try to union something with it when it
is owned we simply append to the the builder. As soon as we need to
actually perform some other calculation on it we force the pendig union
into an actual union. The intmap then becomes the result of this union.

This "becomes the result" can happen in two ways: If we own the result
we simply memcpy it over and free the underlying data. If we don't
own the result this is not a safe operation, so we instead introduce
a redirection where the intmap carries a forwarding pointer that says
"this is who I actually am".

We generalise this to adding a notion of an arbitrary indirect intmap.
Indirect intmaps carry around a payload and an allocator, which allows
us to resolve the indirection in a way that creates new intmaps even
inside non-destructive methods that are not allocator aware. This is
perfectly reasonable to do because indirect intmaps are carrying around
a ton of extra space they're not using.

TLDR, intmap now has the basics of a query optimiser.

PS. We're now beating Haskell's IntMap on my incredibly contrived insertion
benchmarkactually perform some other calculation on it we force the pendig union
into an actual union. The intmap then becomes the result of this union.

This "becomes the result" can happen in two ways: If we own the result
we simply memcpy it over and free the underlying data. If we don't
own the result this is not a safe operation, so we instead introduce
a redirection where the intmap carries a forwarding pointer that says
"this is who I actually am".

We generalise this to adding a notion of an arbitrary indirect intmap.
Indirect intmaps carry around a payload and an allocator, which allows
us to resolve the indirection in a way that creates new intmaps even
inside non-destructive methods that are not allocator aware. This is
perfectly reasonable to do because indirect intmaps are carrying around
a ton of extra space they're not using.

TLDR, intmap now has the basics of a query optimiser.

PS. We're now beating Haskell's IntMap on my incredibly contrived insertion
benchmark. They could easily beat this by using fromList instead if they
replicated intmap_builder's clever stack algorithm, but they currently don't.
intmap_all should use the non-destructive form of redirect following