Decide layering for Android and bionic ARM ABI normalization

> [!NOTE]
> This issue was drafted with GitHub Copilot.

Follow-up to https://github.com/dotnet/runtime/pull/127578.

PR #127578 re-enables `android-arm` CoreCLR runtime pack / CI coverage and fixes the immediate softfp ABI mismatch by teaching the Crossgen2 and NativeAOT ILCompiler frontends to normalize Android ARM consistently:

```text
--targetos:android -> effective TargetOS.Linux
--targetos:android --targetarch:arm -> softfp / armel ABI
```

The PR discussion raised a broader design question that should be tracked separately from the enablement work: where should OS + architecture to ABI normalization live for Android, bionic, Linux, and `armel`?

## Discussion from #127578

There was agreement that Android ARM needs the softfp / `armel` ABI and that Crossgen2 and ILCompiler should not diverge in how they interpret Android ARM target identity.

The open design question is the layering:

- One approach is to keep normalization in the compiler frontends so Crossgen2 and ILCompiler accept the same command-line shape and derive ABI details consistently from OS + architecture.
- Another approach is to normalize closer to RID / MSBuild target handling, since NativeAOT already handles some ABI details in targets and Android / bionic ultimately compile as Linux-like targets.
- Adding `TargetOS.Android` raised the related question of whether `TargetOS.Bionic` would also be needed, or whether both should normalize before reaching the compiler model.
- There was also a suggestion to unify Android -> Linux normalization with the existing `armel` target-architecture normalization path, possibly avoiding a dedicated `TargetOS.Android` enum value.

## Questions to resolve

1. Should `--targetos:android` and/or `--targetos:bionic` be accepted compiler frontend inputs, or should these be normalized before invoking Crossgen2 / ILCompiler?
2. Should Android ARM and bionic ARM infer softfp / `armel` from OS + architecture in the compiler frontend, or should MSBuild/RID handling pass `armel` explicitly?
3. Should `TargetOS` remain fine-grained enough to include Android and potentially bionic, or should these normalize to a smaller set of effective compiler target OS values?
4. Can Android -> Linux and `armel` -> `arm` normalization be handled through the same helper/path so the command-line parsing model is less ad hoc?
5. Can the Crossgen2 and ILCompiler command-line setup stay aligned without duplicating normalization across many MSBuild call sites?

## Desired outcome

Decide and document the intended layering for Android / bionic / Linux ARM ABI normalization, then update Crossgen2, ILCompiler, and build integration accordingly. The follow-up should preserve the behavior needed by #127578 while reducing duplication and clarifying whether Android/bionic are first-class compiler target OS values or frontend aliases for Linux-like effective targets.