Bucket typer delays

[Simn]

While profiling hxb we came across an unrelated problem with typing passes. Delays for those are currently managed in a big (int * (unit -> unit)) list where the integer corresponds to the typing pass. Adding entries browses the list until the priority is equal (or larger for delay_late) and then inserts the new element. Flushing a given pass removes elements until the priority is lower.

The problem with the addition case is that it has linear cost over the number of entries. For example, any addition of the lowest priority PFinal will scroll past all current entries to insert it. This gets even worse because delay isn't tail-recursive, which leads to really deep call stacks.

This PR changes it so that we maintain an array of lists, where the array indices correspond to the priorities. Insertion then just has to index into the array and append to the list, while flushing checks all arrays in order until it finds one with a non-empty list, and then recurses after executing its task.

Importantly, flushing only ever handles the first element it finds for a given pass and then starts over. This is because any delay might insert a higher-priority delay which then has to be processed before the rest of our current priority list. In order to not do too many pointless array lookups, we remember the delayed_min_index, which is the lowest pass whose list might have entries.

While this is clearly the better approach in my head, it would be good to have some profiling data to support this.

[Simn]

It's not very easy to get straightforward profiling data here, but I see in perf that the deep stack trace from delay is gone. Which of course I could have known without perf, because the loop itself is gone. With the delayed_min_index memoization, flush_pass should not suffer any performance penalty either. Will merge accordingly!