[ios-clr] Update Subsets.props to build CoreCLR subset for Apple mobile

[kotlarmilos]

Description

When CoreCLR runtime packs were enabled in #120444, the clr subset isn't being built by default for Apple mobile targets. This issue wasn’t caught before because the CI builds are using the clr+packs command.

[Copilot]

Pull Request Overview

This PR fixes an issue where the CoreCLR subset was not being built by default for Apple mobile platforms (iOS/tvOS/MacCatalyst) after CoreCLR runtime packs were enabled. The fix ensures that when CoreCLR is supported on Apple mobile devices, the clr subset is included in the default build configuration, mirroring the approach already used for Android.

Key Changes:

• Split the Apple mobile default subset configuration into two conditions based on CoreCLR support
• Added RuntimeFlavor detection for Apple mobile when CoreCLR subset is present
• Configured DefaultCoreClrSubsets for Apple mobile platforms

[dotnet-policy-service]

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

[kotlarmilos]

I first pushed this change to codeflow PR dotnet/dotnet#2885, but there is currently a conflict with the latest changes in dotnet/runtime, so I opened this PR instead.

@dotnet/product-construction Please let me know how to resolve the conflict - should I merge this PR and revert the commit in codeflow PR?

[premun]

@kotlarmilos merge here and then we will re-open a new one in VMR - that will be the easiest - I saw Djuradj spotted some other codeflow issues in the VMR one so we'd be doing it anyway.

[steveisok]

Not directly related to this, but for the inner loop we should try to tune RuntimeFlavor better when building the coreclr or mono version separately. Right now it's locked and if you're on the opposite runtime, you always have to specify the property when running tests.