Support MLton-style aggressive type inference

[shwestrick]

Problem

Millet reports a 5023 error for the definition of f here:

type foo = {x: int, y: string}

fun f foo = #x foo

fun g (foo: foo) = f foo

However, this code is accepted by MLton. The reason MLton accepts it is because the type of f can be fully inferred within the definition of g. (You can confirm this deleting the definition of g; MLton will then reject it.)

Solution

It would be nice for Millet to optionally support more aggressive type inference, to mimic MLton.

Perhaps this could even be enabled by default when workspace.root is a .mlb.

[azdavis]

Put this test in as a failing test in 8973f80.

Supporting this would be somewhat non trivial. I'd have to think about what sort of invariants we currently rely on by generalizing per declaration, that would be broken if we started doing it across declarations. It'd also probably just be a bit of work to restructure the way we generalize to be able to do this.

Here's where we do generalization for val decs; this is also thus currently the only place we emit the unresolved record ty error.