[release/9.0.1xx] Update MSB3825 warning presence

[github-actions]

Backport of #45861 to release/9.0.1xx

Contributes to dotnet/msbuild#11185

Summary

Based on BinaryFormatter removal workgroup recommendation, MSBuild should stop warning in the GenerateResource task about possible usage of BinaryFormatter during runtime - as in the NET9 the usage of the BinaryFormatter is avoided during runtime.

More details: dotnet/msbuild#11185 (comment)

Customer Impact

User can be receiving false postivie warnings about security related topic - which might decrease credibility of similar warnings and customers attention to true positives.

Regression?

No.
BinaryFormatter used to be used in runtime up till NET8 - and there was no higher runtime then - so the warning was correct unconditionally.

Testing

Tested via manual run of dotnet build with GenerateResource targeting NET8 and NET9 - warning appears only in the former.

Risk

Minimal (just a comparison change).

[marcpopMSFT]

@JanKrivanek are you going to prep the QB mode tab and bring to tactics for approval

[JanKrivanek]

@marcpopMSFT Asked for tactics approval.
Once done I can create shiproom bugs and ask 17.12 and 17.13 QBs approval. Just let me know if you'd have any concerns or would want to group with any other stuff you're possibly inserting.

[JanKrivanek]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[JanKrivanek]

@dotnet/domestic-cat the failing tests are unrelated to the payload backported (what fails is a different ordering of dotnet new --list command, while here we are changing presence of BinaryFormatter warning during build).

Can the tests be taken care of?

[Forgind]

@dotnet/domestic-cat the failing tests are unrelated to the payload backported (what fails is a different ordering of dotnet new --list command, while here we are changing presence of BinaryFormatter warning during build).

Can the tests be taken care of?

I may be wrong, but I think I remember a runtime issue that had similar symptoms. That one was fixed already, and I would've expected /azp run to have remerged release/9.0.1xx into this, but I still have an 'update branch' button to click, so maybe I'm wrong about that. I'm going to try that and see if it works. It's also possible that only went into a later branch.