add a NO_INTMAP_POOL flag which disables the use of all the allocation optimisations from intmap_pool and just uses straight malloc/free. This caused me to find a bug in debug mode where we weren't correctly writing the debug information for ownership assertions
A bit of a mix.

Trivial things:
  * Add intmap_contains API. Currently no faster than just doing lookup().present
    but slightly easier to use and could be optimised later.
  * Add intmap_range API which creates an intmap with a range of keys pointing to
    a given value.
  * Fix some tests that weren't printing their name.

More interesting thing:

Add an intmap_intersector API analagous to the intmap_builder. Designed to do large
intersections of intmaps as efficiently as possible.

Primary idea behind it is that because you can commute all but the left-most element
of an intersection we are free to always intersect the smallest value. We maintain a
binary heap of 128 elements to be intersected. When this fills up or we start intersecting
the smallest element with the base of the intersection. When we complete we just iterate
the heap in order which is faster and roughly in size order.

This is interesting for two reasons:
  * It mostly does small intersections, which are faster
  * By mostly intersecting small sets it greatly increases the chances of reducing the
    base element to 0 or 1 at some point. Once that happens we have much faster options
    and can start shortcutting pretty heavily.
when given a pending union and asked to remove it from another intmap it's more efficient to sequentially remove each chunk - it safes work and is likely to terminate early