Look into .NET 9's `PersistedAssemblyBuilder` to enable DynamicProxy tests on .NET Core

[stakx]

Not being able to save dynamically generated assemblies to disk on .NET Core has made it impossible to run most DynamicProxy tests on that runtime, meaning we had an increasingly large blink spot regarding new runtime & C# language features. The availability of something like PersistedAssemblyBuilder (if it is what it looks like) means we can finally close that gap and run all DP tests on .NET Core.

A prerequisite for this is enabling .NET 9 or later as a TFM. There's ongoing work towards that direction, which should therefore be dealt with first.

[stakx]

Judging from a first quick read of this article, I suspect that PersistedAssemblyBuilder might not fit well into DynamicProxy's existing architecture, mainly for two reasons:

1. Generated types seemingly cannot be run right away. The assembly needs to be saved first, then reloaded back into nemory, in order to be runnable. It might be possible to adapt existing generator classes such that they generate a type without immediately instantiating them in GenerateType. We'd likely need a specialized ModuleScope that is good for generating a single type only. (Should only be exposed to the test projects.)

2. Emitted types cannot be fully inspected, especially not before saving the assembly to disk. This might break various pieces of the collector & generator classes.

I'm hoping I am wrong but I suspect that making use of PersistedAssemblyBuilder would require a fairly extensive refactoring or even a rewrite of DP internals.

[stakx]

Thinking about this again a few months later...

Since types generated via PersistedAssemblyBuilder cannot be instantiated right away, the dynamic assemblies containing them first need to be written to memory or disk, then loaded into the runtime. This has a few implications:

• We likely still need the mechanism of loading an assembly's types into the proxy generator cache, which currently appears to have some ties to binary serialization (see Remove support for serialization? #562 (comment)). Is there a way to decouple it from serialization (which we'd possibly like to remove)?

• Either we emit one assembly per type (which may or may not be inefficient... I haven't run any tests on this), or we find some way of separating the proxy type generation and the proxy type instantiation and "batching" the former. Think e. g. a builder pattern approach:

  var proxyGeneratorBuilder = new ProxyGeneratorBuilder();
  proxyGeneratorBuilder.CreateInterfaceWithoutTargetType<IFoo>();  // return type `void`; no `Type` would be returned!
  proxyGeneratorBuilder.CreateClassProxyType<Bar>();
  
  proxyGeneratorBuilder.SaveAssembly(/* stream or file name goes here */);
  // after this, no more types can be created using this builder instance.
  
  var proxyGenerator = proxyGeneratorBuilder.Build();
  // proxy generator retrieved this way would be restricted to the pre-built types:
  var foo = proxyGenerator.CreateInterfaceProxyWithoutTarget<IFoo>();  // OK
  var bar = proxyGenerator.CreateClassProxy<Bar>();  // OK
  var baz = proxyGenerator.CreateClassProxy<Baz>();  // ERROR

  I should add that something like this is not intended to be the future common usage pattern, but it would likely be required in the test suite.