Update field references in property accessors

[cston]

Rename or qualify field references in property accessors to avoid conflict with field keyword in C# compiler preview.

[cston]

cc @jaredpar, @stephentoub

[jaredpar]

@stephentoub the current plan is that field will be under langversion preview at .NET 9 RTM. These projects build with langversion preview and hence will hit the new behavior during source build.

Think there are a couple of options for how we could deal with this:

1. Take this PR and then back port to the rel/net9.0 branches
2. Flip these projects to <LangVersion>latest</LangVersion> in the rel/net9.0 branches
3. Patch source build.

[stephentoub]

Think there are a couple of options for how we could deal with this

I'd like to do (1), and only fall back to one of the others if we struggle to get the backport in. We should merge this PR, regardless, as it's the path forward and what we'd want for 10.

[stephentoub]

@cston, @jaredpar, I assume we've validated this is the complete change necessary for release/9.0 to successfully build with the new compiler bits?

[stephentoub]

/backport to release/9.0

[github-actions]

Started backporting to release/9.0: https://github.com/dotnet/runtime/actions/runs/11025343810

[cston]

I assume we've validated this is the complete change necessary for release/9.0 to successfully build with the new compiler bits?

Unfortunately, there is at least one more use of field within an accessor here. (I'm not sure how I missed that case when I built earlier.)

To find any remaining cases, I may need to create a PR that references the updated compiler nupkg and rely on the build from dotnet/runtime CI.

[cston]

Unfortunately, there is at least one more use of field within an accessor here.

Updated in #108225.

When we have an updated compiler package, I'll reference the compiler nupkg in #108225 to catch any additional compile errors in CI.