Update field keyword breaking change diagnostics

[cston]

With -langversion:preview, the token field, when used as a primary expression in a property accessor, binds to the synthesized backing field for the property. That is a breaking change when there is another symbol in scope named field that the compiler would have bound to with earlier language versions. The compiler reports a warning in -langversion:preview for those cases.

A couple of issues have been reported regarding the current warning:

1. The warning does not match the Breaking change warnings proposal. In that proposal, warnings are reported in earlier language versions that the behavior will change rather than warning in later language versions that behavior has changed.

2. The warning is reported for a reference to field, but not for a declaration of a local or parameter named field within the accessor, even though field will not bind to that variable. (To bind to the variable, use @field.)

We should consider updating the diagnostics to address these issues.

[CyrusNajmabadi]

The warning does not match the Breaking change warnings proposal

Yes. This seems important. We're using 'field ' to trial out the breaking change experience. So we should not deviate from the design there without good reason.

[jaredpar]

The warning is reported for a reference to field, but not for a declaration of a local or parameter named field within the accessor, even though field will not bind to that variable. (To bind to the variable, use @field.)

I think that we need to draw inspiration from value here. Within an accessor it's not possible to declare a local named value because it would effectively shadow the implicit parameter. Given that we try and mirror field and value as much as possible, I think that we should error on local declarations. If you want to keep the local declaration then name it @field.