Accessors Annotation should allow deprecating generated methods

See also eclipse/xtext-xtend#903.

The @Accessors annotation lacks the ability to deprecate the accessors, even when the field is marked as @Deprecated.

Rationale: In some cases, deprecating API is required, and in the case of large projects, it is significantly easier to just enable deprecation warnings to change uses of old API than to manually look through all usages of the field and its accessors.
In other cases, only deprecation (perhaps for removal or renaming) of the accessors and not of the field is required. Therefore, a way of independently deprecating the methods is requried.

Proposed fix: See PR eclipse/xtext-lib#317. The methods are deprecated when the field is tagged as such, and manually deprecating them can be done by setting the flag Accessors.deprecate.

Missing features: forRemoval and since data delegation to the generated annotations. Deprecation reason delegation to the generated methods.

Start by reading the Accessors annotation and comparing the proposed approach in eclipse/xtext-lib#317. Verify how generated accessors inherit field deprecation and how Accessors.deprecate controls them. Done means supporting independent accessor deprecation and addressing the listed forRemoval, since, and deprecation-reason delegation gaps.