XmlSerializerGenerator tests get in the way when change is expected

[StephenMolloy]

This is a test issue. The tests for XmlSerializer are broken when the output from
the tool is expected to change with a PR. That's because the test project launches
the pre-installed older version of dotnet.exe to produce a serializer code file, and
then calls the newly built generator binary to create another serializer code file,
and then compares the two. In theory, the idea is that nothing should change
between the two, and if something does change, that means the PR broke
something.

Which is not the case when testing a PR that is expected to change the serializer
code being generated. (Like adding support for a new primitive type for example.
Like we're doing in #55101.)

I'm going to disable the XmlSerializerGenerator tests in that PR while it gets
merged, and we can re-enable them when the pre-installed dotnet.exe catches up.

[MichalStrehovsky]

Is this the same as #54470?

[StephenMolloy]

Yup. I must have missed that one.

But I think this one can stay assigned to me and be used for short-term tracking to remind me to re-enable the SGen tests, while the other bug can remain active (and pushed to the future if necessary since it's a test issue) so the team can decide on a better approach and fix this set of tests in the future.

[StephenMolloy]

Addressed in #56877.