If a TP instance is not collected it keeps very large amounts of state alive

[dsyme]

We have observed in traces related to #6409 that if a TP instance is not collected then it keeps very large amounts of state alive.

This can happen when:

1. TP instances have mistakenly kept themselves alive by F# compiler not disposing them correctly
2. If a TP registers itself in global state, e.g. in a callback in a file watch timer or stores itself in global state in its own DLL
3. if a TP saves one of its generated ProvidedTypeDefinition in a global cache in its own DLL

Regarding (1) - Obviously if there are compiler bugs we should fix them, but (2) and (3) are also real possibilities.

In these cases, the TP holds an invalidation callback object in its Invalidate event. This invalidation callback should not keep compiler state such as IncrementalBuilder and TcImports alive if it is otherwise eligible for GC.

One defensive coding strategy is to add a weak reference at the callback.

This is a reasonable step for reducing the impact of coding mistakes in type providers.

Repro steps

Repro would involve creating a bad type provider that saves the TP instance into global state.

• Operating system
• Branch
• .NET Runtime, CoreCLR or Mono Version
• Editing Tools (e.g. Visual Studio Version)
• Links to F# RFCs or entries on https://github.com/fsharp/fslang-suggestions
• Links to performance testing scripts
• Indications of severity