Fix LoaderAllocator computation for a generic type instance

[alexey-zakharov]

ClassLoader::ComputeLoaderModuleWorker uses a LoaderAllocator creation number to determine the latest LoaderAllocator to place a class in. However the method does not account the number of the type definition itself when calculating the latest number and this can lead into a situation when the generic instance is put into the older LoaderAllocator.

E.g. if we have type ClassA from AssemblyLoadContext A with number 2 and type ClassB from AssemblyLoadContext B with number 5 the resulting loader allocator for the type ClassB would correspond to AssemblyLoadContext A. If ClassB contains a static, such static would be then placed under the LoaderAllocator A, preventing AssemblyLoadContext B from unloading.

The PR updates the ComputeLoaderModuleWorker logic to account for the LoaderAllocator of a defining type, so we use it if it has the latest creation number

[alexey-zakharov]

@joncham I did run tests locally and seems like upstream tests are fine too for the change
given that this change solves our issue with ALC leak, I would like to merge it and if anything is updated upstream - I'll merge it back to our fork