Add type providers support for the transparent compiler

[nojaf]

Description

Hi @0101,

Trying to add support for type-provider to the transparent compiler.
This is a bit hard to explain so I made a quick recording:

fsharp-type-provider-trabsparent-compiler.mp4

Open questions are:

• How to unit test?
• What caches need to be invalidated?

//cc @dawedawe

Fixes # (issue, if applicable)

Checklist

• Test cases added

• Performance benchmarks added in case of performance changes

• Release notes entry updated:

  Please make sure to add an entry with short succinct description of the change as well as link to this pull request to the respective release notes file, if applicable.

  Release notes files:

  • If anything under src/Compiler has been changed, please make sure to make an entry in docs/release-notes/.FSharp.Compiler.Service/<version>.md, where <version> is usually "highest" one, e.g. 42.8.200
  • If language feature was added (i.e. LanguageFeatures.fsi was changed), please add it to docs/release-notes/.Language/preview.md
  • If a change to FSharp.Core was made, please make sure to edit docs/release-notes/.FSharp.Core/<version>.md where version is "highest" one, e.g. 8.0.200.

  Information about the release notes entries format can be found in the documentation.
  Example:

  • More inlines for Result module. (PR #16106)
  • Correctly handle assembly imports with public key token of 0 length. (Issue #16359, PR #16363)
    *while! (Language suggestion #1038, PR #14238)

  If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

[github-actions]

⚠️ Release notes required, but author opted out

Warning

Author opted out of release notes, check is disabled for this pull request.
cc @dotnet/fsharp-team-msft

[0101]

That looks good!

One thing to think about: so far we never actually had to manually invalidate any caches, rather everything is driven by constructing the appropriate key for each computation that describes what that computation depends on. I feel it makes reasoning about the whole thing a bit easier. It would be good if we could keep with it, however in this case it might be a bit tricky, so we can probably make an exception.

Wonder if something could be doable inside FSharpProjectSnapshot that would be handling the change event. But ultimately the responsibility would probably have to be shifted to the user of the compiler. So when types are invalidated they would have to re-request with new snapshot (with some type-provider version bumped up).

[nojaf]

@0101 I'm really unsure how to write a proper test that would mimic the behaviour of an invalidating type-provider.

This PR has already improved the situation. Could we revisit this maybe some other time?

[0101]

Thanks for moving this forward!

This may not be the ultimate solution but it should hopefully unblock most of basic type provider use cases. We can further improve it in the future.