Adjust embeddedresource culture warning

[JanKrivanek]

Fixes #11313

Context

The newly added MSB3002 has a breaking potential (while it's very correct). So making it an opt-in behavior

[SimaTian]

What is our heuristic for selecting between

• changewave
• opt-in
• opt-out (different than a changewave, do we ever do that?)
  please?

[maridematte]

Isn't this the exact case why we have changewaves? It is a good change that we do want to enforce, but with an adoption period for breaking cases / edge cases.

[JanKrivanek]

We discussed this offline with @rainersigwald and decided for opt-in behavior. So ChangeWave (which was here previously) is not an optimal choice now.

The opt-in/out decision is basicaly per case decision based on the "breaking potential" vs "improvement"

[JanProvaznik]

[rainersigwald]

changewaves are "we believe no one will be impacted by this but we aren't totally sure so let's evaluate". That's not appropriate here: before release we've broken the two repos closest to us, so we know it's breaky.

Opt-ins are for behavior that is like this: breaky but also "clearly right". Then we can have the SDK opt in in new .NET versions or apply BuildChecks to encourage people to opt into stuff.

Opt-outs without changewaves used to be how almost everything was done (which is why we have so many) but now we prefer changewaves (which go away eventually, leaving less ugly code). However, if we expect people to reasonably want differing behavior in different circumstances they can be reasonable.

[rainersigwald]

This targets main. Doesn't it need to be a 17.13 QB fix?

[JanKrivanek]

Ported to #11320
Let's then get it by codeflow