Fix #2134: Instantiate generics in expected function types before sub…

[Definisi]

When calling addIndex(filter) where:

• addIndex has type <A, B, C>(op: ((value: A) -> B, array: {A}) -> {C}) -> ...
• filter has type <A, K>(predicate: (value: A) -> boolean, tbl: {[K]: A}) -> {A}

The type checker incorrectly reports:

No valid instantiation could be inferred for generic type parameter A.
It was expected to be at least: A and at most: A & C but these types are not compatible with one another.

This happens because the generics A, B, C from addIndex appear in the expected type's signature, and when checking if filter matches, the solver treats them as the same generics as filter's own A, causing a name collision.

Solution

The fix instantiates generics from the calling function with fresh types before performing subtyping when the expected argument type is a function type containing those generics. This ensures that generics from the outer scope don't conflict with generics from the actual function type being checked.

Specifically, in ConstraintSolver::tryDispatch for FunctionCallConstraint, when checking argument types with pushTypeInto, we now:

1. Detect if the expected type is a function type containing generics from the calling function
2. Instantiate those generics with fresh types (using freshType and freshTypePack)
3. Use the instantiated type for subtyping checks

This prevents generic name collisions and allows correct type inference.