Add win-arm64 to default RIDs

[ladipro]

Summary

As pointed out by @zivkan in AB#1698505, the default RID list is missing win-arm64, which manifests as a failure to restore packages when targeting Windows ARM64 in legacy (non-SDK style) projects.

Fix

win-arm64 is a first-class supported platform so it is added to the default RID list, as suggested

Testing

Verified that the scenario of restoring an ARM64 .NET Framework app in Visual Studio works with this change.

[ladipro]

Asking @tmeschter for review per repo ownership.

[tmeschter]

Manually kicked off a build and it passed. Merging.

[fowl2]

Hi team, this breaks the build for non-sdk style projects using lock files see NuGet/Home#12711 for more details.

Is it possible this could be conditioned only on new TFMs?

[ladipro]

Thank you for reporting this!

Is it possible this could be conditioned only on new TFMs?

Definitely possible but I'm not sure if it's correct to require developers to target 4.8.1 to build for arm64. For what it's worth, VS allows adding ARM64 as the project platform regardless of which Framework version is targeted. @tmeschter what do you think?

[fowl2]

Is there a scenario where targeting pre 4.8.1 but including arm64 components makes sense? Given the only way to actually run an exe like this is using the IFEO registry key or start /machine? Maybe a library?

[ladipro]

My experience with arm64 is limited but I would expect it to be fairly common to add the ARM64 platform to an existing project which targets an older version of the 4.* Framework, simply to make it run natively on arm64 HW. I don't think the version of the runtime actually used being 4.8.1 is super relevant. Framework has strong back-compat guarantees so targeting, say 4.5, and running on 4.8.1 should be fine.