Respect property to disable targeting pack caching for runtime build

#19570 introduced caching in ResolveTargetingPackAssets. I’m not aware of complaints from “normal” users, but for the dotnet/runtime repo, which produces those targeting packs during its build, the caching can preserve stale data.

I think this is becoming an issue in between using dotnet build on source projects where the caching feature is not disabled as the env var is only set on the build scripts and then using dotnet build or dotnet test on a test project where the platform manifest is needed.

@rainersigwald is it possible that we can also support an MSBuild property to disable the targeting pack caching?

_Originally posted by @safern in https://github.com/dotnet/runtime/issues/61451#issuecomment-982812791_

[rainersigwald]

We opted not to have existence/timestamp checks for cache invalidation for this particular cache because it doesn’t generally change for users during a process lifetime since everything in it is part of the .NET SDK. Timestamp checks can be surprisingly expensive.

We can add them, but I’d prefer not to if we can get away with opting into “unstable targeting pack mode” in limited circumstances like “the runtime build”.

[rainersigwald]

Yeah, we can add an input to the task and pass a property through to it. It would require an SDK update. @marcpopMSFT would you have any objection to adding such a feature to an SDK task when the only expected consumer is the runtime build? I personally don’t . . .

_Originally posted by @rainersigwald in https://github.com/dotnet/runtime/issues/61451#issuecomment-982815610_