Add Worklist implementations

[haved]

To avoid one big PR, here is the set of worklist implementations I have, used by the new Andersen solver.

I decided to use tightly packed vectors instead of HashMaps / HashSets. This can of course be benchmarked later.

[phate]

I got interrupted and could not finish my review. I will need to have another look at it. Just leaving what I have so far.

I am a little bit worried about the template parameter only being of integer type as this would limit the usefulness severely.

[haved]

I implemented your suggested changes, and fixed the tests (always test with --enable-asserts...).

While I think performance might be better with std::vectors, it does make the interface less general, so I moved it to util::HashSet and std::unordered_map for now. The worklist is a tight part of the algorithm, so it will be interesting to see in the future if it has an effect.

[phate]

The main issue I have is that this should live in libutil and not in the alias-analysis subdirectory. This is quite useful for other parts in the compiler.

I agree with you that using std::vector would be more performant due to caching effects, but that should be possible by using template specialization:

template<>
LifeWorklist<size_t> : public Worklist<size_t>
{
...
}

(written by heart, syntax might be off)
where you provide another implementation with std::vector. In other words, we can have the cake and also eat it. The cost is another implementation (and tests).

[haved]

I moved it to util, and started on specialization for integer types, but ended up with SFINAE fluff that didn't look that nice by the time it worked, so I'm trying to make it a bit more sane first

[haved]

I ended up not adding specializations for bounded integer typed Worklists now, as it always became quite ugly. The best solution I found was to create a class with the same interface as util::HashSet<T>, but enforce T to be integer and the bounds to be provided in the ctor. The same would have to be done for util::HashMap<K,V>, but we currently don't even have our own util::HashMap<K,V>, and it felt a bit overkill to add that now.

Also, I didn't opt to use std::move(), as this class really shouldn't be used unless std::is_trivially_copyable_v<T> either way.

Instead, I will investigate if preallocated sequential vectors makes a difference once the Worklist actually is in use.