Always enable static linking when dynamic code compiled feature is false

[BrzVlad]

If dynamic code compiled feature is false then we produce the interpreter library, which currently doesn't have a PlatformManifestEntry. Rather than including this in the manifest entries, simply link the interpreter library into the runtime.

[dotnet-policy-service]

Tagging subscribers to this area: @BrzVlad, @janvorli, @kg
See info in area-owners.md if you want to be subscribed.

[BrzVlad]

@jkotas Hitting a failure for the packs build, I remembered there was this other reason for enabling static linking when dynamic code compiled feature is false. I've included another commit (which was then reverted) on the PR, that adds conditionals on the platform manifest entries (the target os checks might actually not be needed since I suspect we don't publish to nuget from those builds). Anyhow, I'm not enthusiastic about this debug feature option creeping its way into those packaging msbuild targets and ensuring their correctness. Therefore I went back to the simple solution of just enabling static linking. Let me know which approach you think works best.

[Copilot]

Pull request overview

This pull request modifies the CoreCLR feature configuration to enable static linking when dynamic code compilation is disabled. The change ensures that the interpreter library is statically linked into the runtime on desktop platforms when FEATURE_DYNAMIC_CODE_COMPILED is false, avoiding the need for platform manifest entries in pack builds.

Changes:

• Extended the FEATURE_STATICALLY_LINKED condition to include scenarios where FEATURE_DYNAMIC_CODE_COMPILED is false, in addition to the existing mobile platform checks (WASM, iOS, tvOS, macCatalyst)