As I don't see any way to revive the original PR I accidentally
merged in and then reverted, I have created a new one. In the initial
commit I have pushed the previous change. As the second commit
I have added the CompilationModuleGroup change suggested by
Simon - using separate sets for input assemblies vs. for the
version bubble.

This change modifies the existing --inputbubble CPAOT option
to work the same as Crossgen /largeversionbubble i.e. the main module
and all reference assemblies are considered to belong to the same
version bubble.

The gist of the change deals with encoding module overrides in
signatures. I have implemented a new R2R header table
ManifestMetadataTableNode and added logic for composing and emitting
the extra AssemblyRef list.

One challenging bit was that we need to emit all the signatures before
emitting the ManifestMetadataTableNode because only the emission
of the signatures shakes out all the required AssemblyRef's. I have
added a simple loop to ImportSectionsTableNode / ImportSectionNode
that traverses and emits all registered import cell signatures.

For instance entrypoints, I didn't find any manner of encoding
a module override for their signatures in the native hashtable so
for now I added filtering that we're only storing those instance
entrypoints that have the current input module as the reference
module. One can theoretically imagine that a module may contain
arbitrary generic instantiations spanning other modules when
larger bubbles are on.

While working on the change I also realized that the current way
of basing signature contexts on input modules in CorInfoImpl.ReadyToRun
was incorrect - when a method gets inlined, we still need the original
signature context because that's what defines the ambient module
used in the CoreCLR signature parser.

I have deleted the field and instead I added a new method
GetSignatureContext which currently returns
ReadyToRunCoregenNodeFactory.InputModuleContext. Once we start
implementing "single-file" (i.e. compiling multiple MSIL modules
into a single PE), we'll change this to something more fine-grained,
most likely based on some lookup on MethodBeingCompiled.

I found out that part of the framework libraries were crashing
in release build with large version bubble on due to the presence
of duplicate symbols. I found out that CPAOT was still inconsistent
w.r.t. means for formatting typesystem entities in AppendMangledName
methods. I went over all these methods and unified them to use
the name mangled for formatting types, methods and fields. As part
of this cleanup I could subsequently remove the WriteTo methods on
RuntimeDeterminedTypeHelper that are no longer needed.

Rerunning the Pri#1 tests with my new support for issues.targets
filtering out some annoying timing out GC tests I found out that
several tests failed during CPAOT compilation in the manifest
metadata table node. It turns out that the AssemblyRef metadata
table is not always unique, in particular I hit duplication of
the "mscorlib" reference in the table. This change makes CPAOT
resilient towards this type of issues.

Thanks

Tomas

When determining reference module for encoding type
signatures, we're special-casing primitive types as
they don't need any reference module and use special
constants in the signature encoding scheme. I previously
didn't realize that object and string need the same
treatment. I have also added an explanatory comment to
Program.cs as to why we're using a try block when
opening reference modules.

Thanks

Tomas