Remove the crossgen2 TypeRef workaround for trimmable-static type maps

The trimmable-static registrar generates its type map assemblies (`_.TypeMap.dll`) with Mono.Cecil, so the types named by the type-map entries only appear as assembly-qualified name strings in the custom attribute blobs — the assembly has no `TypeRef` row for them.

That's valid metadata (ECMA-335 II.23.3 only requires the type to be stored as a *SerString* holding its canonical name, and neither the `CustomAttribute` (II.22.10) nor the `TypeRef` (II.22.38) validity rules require a matching `TypeRef` row), but crossgen2 assumes the row is there and crashes with a `NotImplementedException` in `ModuleTokenResolver.GetModuleTokenForType` when ReadyToRun-compiling the type map assembly.

Filed upstream as https://github.com/dotnet/runtime/issues/131527.

Until that's fixed, `TrimmableRegistrarStep.EmitTypeReferencesForTypeMaps` works around it by emitting an unused `.KeepTypeReferences ()` method that does `ldtoken` + `pop` for every externally defined type the maps name, which forces Cecil to emit the `TypeRef` rows. It's gated on CoreCLR + `PublishReadyToRun`, because that's the only configuration that needs it, and the extra metadata isn't free (it adds ~64 KB per runtime identifier to `_Microsoft.macOS.TypeMap.dll`).

Once https://github.com/dotnet/runtime/issues/131527 is fixed and we've moved to a runtime that contains the fix, remove:

- `EmitTypeReferencesForTypeMaps` and its call site in `tools/dotnet-linker/Steps/TrimmableRegistrarStep.cs`
- and update the expected app sizes if any of them change.

Start in tools/dotnet-linker/Steps/TrimmableRegistrarStep.cs and inspect EmitTypeReferencesForTypeMaps plus its call site. Check the upstream crossgen2 issue and the linked work before changing anything, then review expected app-size tests or baselines. Done means the workaround and call site are removed after the runtime fix is available, with affected size expectations updated.

Written by the indexing model from the issue text.