Decide on keyword order for `impl`, `mut` restrictions

[jhpratt]

Both impl and mut restrictions were approved in RFC 3323.

For mut restrictions, the syntax was specified as

StructField :
   OuterAttribute*
   Visibility?
+  MutRestriction?
   IDENTIFIER : Type

TupleField :
   OuterAttribute*
   Visibility?
+  MutRestriction?
   Type

Neither the restrictions RFC nor unsafe fields RFC specify the relative order of the newly-introduced keywords (both appearing between visibility and the identifier/type).

Similarly, the restrictions RFC specifies

Trait :
   unsafe?
+  ImplRestriction?
   trait IDENTIFIER
   GenericParams? ( : TypeParamBounds? )? WhereClause? {
     InnerAttribute*
     AssociatedItem*
   }

as the syntax for impl restrictions.

In my PRs parsing impl restrictions, I put the restriction before unsafety, so as to group it with visibility. This was contrary to what was specified in the RFC and was noticed during review.

Given that I personally authored the restrictions RFC,the initial version of the unsafe fields RFC, and the initial (though ultimately closed) implementation for the restrictions, the fact that I did not know the ordering is concerning. Now that impl restrictions are available on nightly and mut restrictions will be shortly, this is something that should be decided sooner rather than later.

cc tracking issue for restrictions (#105077), unsafe fields (#132922), r-a request for supporting restrictions (rust-lang/rust-analyzer#22021)

Nominating for the lang team to discuss and hopefully decide. I will note that this presumes that the keywords as originally proposed is the desired syntax, which is explicitly an unresolved question from the RFC.

[joshtriplett]

We talked about this in today's @rust-lang/lang meeting.

We had a few different opinions (as often happens with bikesheds), but we were able to roughly agree on logically grouping it with the visibility:

pub(...) impl(...) unsafe const Trait<...>: Supertrait { ... }

struct S {
    pub(...) mut(...) unsafe field: FieldType,
}

That said, staring at examples like these for a while had us evaluating the impl(...) part itself (...sorry... 😅), not least of which because of the visual ambiguity-at-a-glance with impl Trait for Type. Many of us were finding ourselves tempted towards something inside the visibility (e.g. pub(impl in crate) or pub(crate, impl in self), for example, or alternatively an attribute. We don't have immediately actionable guidance there, and wanted to give the ordering guidance above first, but we wanted to make sure you were aware and could weigh in on that.