TargetFramework(s) confusion Check

[JanKrivanek]

Fixes #9880

Context

TargetFramework and TargetFrameworks properties should not be specified in the build script at the same time.

Testing

Tailored unit tests added

Notes

This calls to be unified with the #10635 Check. Let's do that in the separate PR, once this one is merged

[baronfel]

Should this be in MSBuild or on the SDK? Meaning, are TFMs a general MSBuild concept or are they something that applies to managed languages/sdk-style projects only? My intuition was SDK-style projects only and so I would have expected to see this only on the SDK layer.

One thing I'd like to check is that it's very common to have a multi-TFM project, but then build or publish for a specific TFM at the command line using the '-f' parameter, which is passed to the build as a global property. Does this usage pattern trigger the check incorrectly?

[JanKrivanek]

Should this be in MSBuild or on the SDK? Meaning, are TFMs a general MSBuild concept or are they something that applies to managed languages/sdk-style projects only? My intuition was SDK-style projects only and so I would have expected to see this only on the SDK layer.

I'd keep here now as we do not yet have a good concept of 'friend build-in checks'.
I'm open to complains and discussion though

One thing I'd like to check is that it's very common to have a multi-TFM project, but then build or publish for a specific TFM at the command line using the '-f' parameter, which is passed to the build as a global property. Does this usage pattern trigger the check incorrectly?

Global override is allowed. I put this to help link:
https://github.com/dotnet/msbuild/pull/11062/files#diff-e96bdd5e98d7e8729178bfbea183e2e16e385f10219a0d4121b2043a4883d5d9R92-R96

But it should be more specific and clear - I'll imporove.
Thanks for bringing this up!