Constrained monomorphs

[Simn]

This PR adds support for constraints on monomorphs by introducing the tm_constraints field on tmono. When a monomorph is bound via Monomorph.bind, the compiler checks if the binding is valid in check_constraints.

There are currently two sources of constraints:

1. Type parameters with constraints: These now all go through spawn_constrained_monos, which creates the monomorph and adds the constraints from type parameters, if exists.
2. Field access: This replaces open anonymous structures. When a field is accessed on a monomorph that is either unconstrained or has the MOpenStructure flag, a structural constraint for that field is added to the monomorph.

Furthermore, if we have an unbound monomorph after typing a function, that monomorph is Monomorph.closed by using its constraints to find a type.

Some information about related issues:

• Because constraints are now checked upon binding, we have more context. This fixes Constraint check error position is not accurate #9393.
• The example in Merge type parameters #5225 works now, but there's more work to be done here.
• The lua and JVM generators run into problems with [jvm] Delayed inlining is required in some cases #8799. This happens because we might now get more accurate type inference, so an anonymous field access might become a proper class field access now.

For now, my goal here is to "not break anything". Afterwards, we can look into what further possibilities this opens. This includes:

• An alternative to @:multiType
• Removal of the Opened flag for structures
• Additional constraints like array access

I'm not 100% confident in the changes made here, but we have to start somewhere.

[RealyUniqueName]

Shouldn't we also check if anon's fields don't conflict with current constraints here?
I didn't find such a check down the constraint_to_type calls path, and Monomorph.bind is called from various places other than unification.

[Simn]

Yes I think a check is missing here. I think we can do this in classify_constraints, where we're building the fields map anyway. This should avoid any problems with too early unification.

[RealyUniqueName]

Same question for other branches of this match

[RealyUniqueName]

Return value of this function is never used.
It should be changed to unit probably. And Monomorph.close too.

[RealyUniqueName]

I'm not 100% confident in the changes made here, but we have to start somewhere.

I 100% agree. Let's merge this and deal with the issues should they arise.

[Simn]

I'll deal with field constraint conflicts later. That requires some proper handling to avoid getting Unify_error exceptions thrown in places we don't want them. The problem seems pretty difficult to reproduce anyway.