Revisit access member for decorators #52540

We're providing feedback around the access member of decorator context objects. The formal issue is over at tc39/proposal-decorators#494, but we have a few possible outcomes.

If access is amended to have some new API, we should change the API to agree with whatever specified. When that happens, we should consider whether it should be declared with function shorthand syntax to avoid method parameter bivariance issues.

If we can't agree on something, we might need to place a variance annotation on the type parameters just to afford ourselves with some future design space.