…nts under special marker parents (dotnet#124684)

## Summary

When `pNewIntfMT` is a special marker type and its sub-interface in the
interface map has an exact instantiation containing complex type
arguments (e.g. `IList<T>` rather than bare `T`), the previous code in
`LoadExactInterfaceMap` would incorrectly fall through to the old case 4
logic. This checked `EligibleForSpecialMarkerTypeUsage` against `pMT`
rather than `pNewIntfMT`, which could treat a sub-interface still
containing unresolved generic variables as either eligible for special
marker substitution or as an exact match — both incorrect.

## Fix

The old case 4 (exact instantiation) is split into three cases to
correctly handle the situation where `pNewIntfMT` is itself a special
marker type:

- **Case 4**: The sub-interface's instantiation is eligible for special
marker usage relative to `pNewIntfMT` (e.g. `ILayer1<T>` where `T`
matches `pNewIntfMT`'s type parameter). Insert the special marker type.
- **Case 5**: The sub-interface has generic variables that don't match
`pNewIntfMT`'s type parameter (e.g. `ILayer1<IList<T>>`). Since
resolving this requires a full deep substitution, and this is a rare
scenario, we fall back to the retry-with-exact-interfaces pathway which
sets `MayHaveOpenInterfacesInInterfaceMap` and disables the special
marker optimization for this type.
- **Case 6**: The sub-interface is fully concrete (no generic variables)
or `pNewIntfMT` is not a special marker type. Falls through to the
existing `pMT`-based eligibility check, which is correct in these
situations.

A regression test is added covering all 8 combinations of pre-loading
the 3 interface layers' generic type definitions before constructing the
concrete class, to exercise the various orderings that lead to different
code paths through the special marker type logic.

Fixes dotnet#124369

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

…lex type arguments under special marker parents (#124835)

Backport of #124684 to release/10.0

/cc @davidwrighton

## Customer Impact

- [x] Customer reported
- [ ] Found internally

The earlier fix for #123254 did not fix all possible cases where the
incorrect type would be loaded. This fix fills out the special case
matrix some more, and I believe should fix all the issues found.

## Regression

- [x] Yes
- [ ] No

This issue was introduced with PR #120712, and mitigated somewhat with
PR #123520. This fix builds on that fix to fix additional issues found
by @reduckted.

## Testing

The fix includes a fairly large test suite covering possible ways type
loading could fail around this fix. It was missed previously in the
previous small fix as the importance of comparing the fully loaded, and
partially loaded interface maps on the generic type definition was
missed during test development. This fix has also been tested by
delivering a hotfixed build to @reduckted which which he was able to
verify fixed the issues he had seen in production as well as in testing.

## Risk

Low. Its filling out more special cases in the new codepaths added in PR
#123520.

**IMPORTANT**: If this backport is for a servicing release, please
verify that:

- For .NET 8 and .NET 9: The PR target branch is `release/X.0-staging`,
not `release/X.0`.
- For .NET 10+: The PR target branch is `release/X.0` (no `-staging`
suffix).

## Package authoring no longer needed in .NET 9

**IMPORTANT**: Starting with .NET 9, you no longer need to edit a NuGet
package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older
versions.

---------

Co-authored-by: David Wrighton <davidwr@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>