This PR introduces a TopType that gets used when no possible Java type can be determined for a variable. This generally happens when local variables get re-used by the compiler, which means this shouldn't happen when using the LocalSplitter¹.

E.g. a variable gets both java.lang.String and byte values assigned to it; or int and boolean. In these cases there is no common type that the variable could be typed with (including casts), so it results in TopType.

It is also possible to get a TopType[] when a local with incompatible array types overlap. For that to work, I had to allow all types as base types for ArrayType because the TypeResolver might need to create a TopType array type.

Most of the issues with the TypeResolver were related to primitive types, augmented integer types, and arrays.

In bytecode boolean, byte, short, char, and int aren't different types. Figuring out correct and tight types of variables that fall in this category requires keeping track of the value ranges that get assigned to the variables. This caused a bunch of issues, since the augmented integers types that are used to track these value ranges weren't always handled correctly. Particularly with variables with a boolean type caused problems, since they aren't assignment-compatible with the rest of the small integer types.

Another issue that combines primitives and arrays was that you can't upgrade the types of primitive arrays when they get assigned to. For normal reference types a java.lang.String[] can be assigned into a java.lang.Object[] because java.lang.String get be assigned to java.lang.Object, but primitive arrays don't form a type hierarchy, e.g. byte[] can't be assigned to int[] even though byte can be assigned to int.

Here's an example that requires TopType[]:

local = null;
local[0] = "";
local = null;
local[0] = 0;

What's the type of null[index]?
The following example can actually occur in real code because control flow might change the runtime order of the instructions compared to the ordering in bytecode

int[] a = null;
int b = a[0];
a = new int[1];

The type of null[index] is now BottomType (other types are not possible because the array might be an array of primitives or of reference types).

When a type never gets a non-null value assigned to it, it will now get upgraded to java.lang.Object after all other assignment constraints are satisfied. This is the most conservative choice. A possible future enhancement would be to look at the usage of the variable instead of just assignments to it to get a more accurate typing.

Interestingly, this choice means because both these examples can't be differentiated in bytecode:

int[] a = null
int b = a[0]

Object[] a = null
Object b = a[0]

a in the second example can't easily be typed as Object[], since that would be incompatible with the first example.
In these cases the TypeResolver will type both a and b as Object and insert a cast to Object[] before the array access.

Possible future work:

• the biggest enhancement would be to take into account not only assignments but also the uses of variables as constraints. This would enhance some edge cases with arrays. The original paper only has a small section on arrays that describes a very crude method of dealing with arrays that would result in very loosely typed arrays. The current implementation is already significantly better than the paper, but could still do better.
• arithmetic operations with augmented integer types don't result in the tighest possible types ([0..127] + 1 currently results in int but it could just upgrade to [0..32767])
• performance: most of the time is spent querying the type hierarchy; this can probably be significantly improved with caching and/or a custom data structure

Fixes #853