Improve inferring generic parameters

[dcodeIO]

potentially fixes #219
potentially fixes #837

This makes use of the new resolver infrastructure to improve inferring generic types, like in

function test<T>(arr: T[]) { ... }
test(float32Array);
// resolving Array<f32>, inferring T = f32

function test<T,R>(fn: (a: T) => R) { ... }
test(someFunctionTakingF32ReturningF64);
// resolving (a: f32) => f64, inferring T = f32, R = f64

by first obtaining the type of the respective argument containing a type parameter and then matching it, including encapsulated type parameters, against the template.

Still feels a bit fragile as if I'd missed something, so if you spot an issue, let me know :)

[MaxGraey]

Could this PR also potentially fix #837?

[dcodeIO]

Appears to be a different issue caused by ordering, but this PR might help to solve it.

[MaxGraey]

Will be great!

[dcodeIO]

The other issue should be resolved as well with the last commit. Now infers all types first while updating to compatible types, and only then does another pass to do the actual resolving.

[MaxGraey]

It will be great inferring type from argument as well. For example:
Current (with this PR as well) we should:

const arr: i32[] = [1,2,3];
arr.reduce<i32>(((prev: i32, current: i32): i32 => prev + current), 0); // but `0` already infer as `i32`

Will be great don't specify <i32> for T and infer it from last argument like:

arr.reduce(((prev: i32, current: i32): i32 => prev + current), 0);

// other example:
arr.reduce(((prev, current) => prev && current), false);
// infer as arr.reduce<bool>(((prev: i32, current: i32): bool => prev && current), false);

[dcodeIO]

Last commit should fix issues with

arr.reduce(((prev: i32, current: i32): i32 => prev + current), 0);

inferring U <- i32 but I'm not sure about

arr.reduce(((prev, current) => prev && current != 0), false);

yet. What we would have to do there is to have a special case for function expressions without any types that just so happen to be fully specified by inferring other types, creating a new function signature with types that then becomes resolved - or something along those lines.

[dcodeIO]

Wait,

arr.reduce(((prev, current) => prev && current != 0), false);

appears to compile now. I guess the other logic we have for function expressions without types can pick this up now since the code now uses compileCallDirect.

[MaxGraey]

Great! Well done!