Name resolution: keep type vars in subsequent checks

[auduchinok]

This is another approach for reporting type arguments, previously experimented in #14773 and #15628. In the following cases I'd like to make it possible to see the checked/inferred types of I type arguments:

I<int>
I<_>

The previous approaches tried to overwrite reported symbols after the type arguments were checked, but it was quite ad-hoc and didn't work well with type parameters flow in cases like this one:

type I<'T> =
    abstract M: 'T -> unit

{ new I<_> with
      member this.M(i: int) = () }

With that approach we'd need this:

• re-report types after type arguments are checked
• find a performant way to replace previously reported type symbol that lacked inferred type arguments

This PR uses a different approach. It turns out that type variables were already always created for symbol reporting, but they were discarded afterwards and new type variables were created for subsequent type application checking. This is the reason why the initially reported type variables lacked inferred type solution: they never participated in the subsequent checks.

This PR makes the initially reported type variables flow through the subsequent type checking phases, so they have the correct solutions after the checking. This works for reporting types first and checking arguments later, because storing the type inference solutions uses mutation. With this approach, the type instantiations are correctly preserved in the cases like the one above.

This PR is not ready yet, and I want to check what tests fail in CI.

[auduchinok]

This is ready. Type arguments are preserved properly now in the captured items for types. 🎉

However, they aren't accessible via FCS APIs in some cases, so one of the added tests is disabled for now. I'm going to try to rework the type arguments story for FSharpEntity symbols, so 1) type arguments are accessible and 2) less data is duplicated, but it's going to be a separate PR or several of them.

I had to move a bit of code from ConstraintSolver to NameResolution along the way, but there were no changes to this code itself.

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/8.0.300.md

[vzarytovskii]

We shouldn't probably match on ttype directly, need do stripping first

[T-Gro]

I am not sure of this holds for a type instantiation, but it is a good point to add a test case with a type alias as a typar to see what it does.

If we stripped, we would lose the type alias and then it couldn't be searched for as a separate symbol... ?

[auduchinok]

I'm not sure it'd be what we want to achieve here. I'm unwrapping the type variables produced by name resolution logic here, I probably don't want to change them in any way. Another approach could be to refactor more places and to pass the typar instantiation explicitly, but it seems that simply unwrapping it like this works for the cases we're interested in here, i.e. to make the types flow into subsequent checking phases after reporting.

[auduchinok]

Could this get merged, please? 🙂