Evacuate set and map iterators during garbage collection

[dwightguth]

When testing the new_gc branch against the K frontend test suite, we uncovered a problem. If a set or map iterator (resulting from a set or map choice operation during pattern matching) is live during garbage collection, the pointers inside that iterator were not being fixed up to point to the correct semispace, even though the set or map that the iterator was associated with was being relocated by the GC. This led to cases where the forwarding pointer was being treated as if it were a pointer to actual data, which of course caused memory corruption to occur.

The solution is a bit tricky. Essentially, we introduce a new SortCategory MapIterator and SetIterator and split the %iter type in llvm IR into %mapiter and %setiter. This allows our LLVM pass to correctly identify that certain live pointers are pointers to iterators. (We also fix up the address space of those live pointers so that they are treated as garbage-collected pointers by the RewriteStatepointForGC pass.)

We also have to introduce a new change upstream to immer in order to store the information inside the champ_iterator type that is needed in order to correctly compute the base pointers and derived offsets necessary to evacuate the iterator. The upstream PR is here: arximboldi/immer#190. You shouldn't need to review it; the maintainers of the library will. Feel free to refer to it for reference though if you want to understand what is happening in our PR.

Once all these changes are introduced, we simply have to modify the collection routine to correctly evacuate the pointers inside these objects. We do this by recording them as needing evacuation when we iterate through the list of roots, and then performing a last stage of garbage collection after evacuating the old generation, where we evacuate the pointers that we stored earlier. This does rely on a certain internal knowledge of the storage layout of iterators in the immer library, but since we are pinned to a specific commit, this is fine. It will just need to be potentially updated if we bump the submodule version, but we don't do that terribly frequently.

Also included in this change are some quick changes to the search function's top-level logic. Basically, instead of storing the results of a single rewrite step on the heap, we store them in a global variable and then use the existing migrateRoots functionality to handle fixing up the pointers to the search results when garbage collection happens. This is necessary because it is possible for a step to compute several search results, trigger garbage collection, and then continue with further pattern matching, in which case the garbage collection algorithm has to be able to fix up the pointers to search results that were already computed prior to collection. This was simply the easiest way of accomplishing this.

[Baltoli]

A couple of minor points that may not actually need addressing, but otherwise LGTM.