Use generic CFG splitting to add a new type of split for exception handlers,
`ExceptionHandlerSplit`, which tags eachs node belonging to a `catch` clause
with the type of exception being caught. This allows for a more accurate CFG
for `try-catch` statements, where exception filters are handled properly.
Refactor existing logic for splitting control flow nodes belonging to a `finally`
block. A `Split` defines (1) when to enter the split, (2) when to stay in the split,
and (3) when to leave the split. With only these definitions, control flow splitting
is achieved by tagging each control flow element with the set of splits that apply
to it.
A default re-export (not part of the standard yet) looks like this:
```
export f from 'mod';
```
What this means is that the default export of `mod` is re-exported under the name `f`.
Default re-export specifiers (like `f` in this example) are modelled as a kind of default export specifier in our library, but unlike normal default export specifiers they do not export the name `default`.
This was previously not modelled correctly, leading to surprising errors down the line, for example in type inference where we suddenly would no longer be able to resolve an import that otherwise looked resolvable.
Casts to `void` did not have a semantic conversion type in the AST, so they also weren't getting generated correctly in the IR. I've added a `VoidConversion` class to the AST, along with tests. I've also added IR translation for such conversions, using a new `ConvertToVoid` opcode. I'm not sure if it's really necessary to generate an instruction to represent this, but it may be useful for detecting values that are explicitly unused (e.g. return value from a call).
I added two new sanity queries for the IR to detect the following:
- IR blocks with no successors, which usually indicates bad IR translation
- Phi instruction without an operand for one of the predecessor blocks.
These sanity queries found another subtle IR translation bug. If an expression that is normally translated as a condition (e.g. `&&`, `||`, or parens in certain contexts) has a constant value, we were not creating a `TranslatedExpr` for the expression at all. I changed it to always treat a constant condition as a non-condition expression.
