Garbage Collection for range maps

[mariaKt]

This PR implements garbage collection for range maps.

The current implementation of the range map's underlying data structure, the red-black tree, is using shared pointers to the internal nodes and leafs of the tree (i.e., the pointer to the root and pointers to left and right children are shared_ptr). This means that we do not need to manage those internal nodes and leaf structures as part of the llvm backend's garbage collection. However, the contents of the map (i.e., the key and value KItems) should be migrated during garbage collection when we migrate an object that contains a range map as a child. We do that by traversing said range map at the time of migration of the parent object, and migrating every such key or value KItem while updating the pointer to it on the corresponding internal node of leaf structure.

We include a KORE test that is based on extending IMP with keywords for certain range map operations. The inputs are currently small IMP programs with a few different interleavings of update and remove operations. We will use the C semantics (whose memory cell, currently a map, will be replaced by a range map) and its test suite for more extensive testing after we complete that implementation.

Note: This approach may lead to memory fragmentation/leaks for large programs. Data pointed to by memory managed by the C++ runtime (shared pointers) may not be deleted/deallocated, but instead be overwritten after the llvm garbage collection is completed. This means that reference counting will not be updated for these shared objects, thus they may never be returned to the system.
If we observe this to be an issue, we can address it in a future PR by changing the implementation of the red-black tree to not rely on shared pointers but instead use memory managed by the llvm backend (kore-alloc) for the internal nodes and leafs as well, and migrate these additionally during garbage collection.

[Baltoli]

One minor comment; tests + code look great otherwise. Nice work @mariaKt!

[dwightguth]

pretty simple. I like it! As you say, if there are issues with performance regarding the shared pointers we can create a followup PR to deal with those.