Auth rules don't explicitly prevent `m.room.create` events from having `auth_events`.

Originally from #1048.

Link to problem area: https://spec.matrix.org/v1.2/rooms/v9/#authorization-rules

Issue

The auth rules begin:

1. If type is m.room.create:
   1. If it has any previous events, reject.
   2. If the domain of the room_id does not match the domain of the sender, reject.
   3. If content.room_version is present and is not a recognised version, reject.
   4. If content has no creator field, reject.
   5. Otherwise, allow.

This doesn't restrict the auth_events on m.room.create events. The auth events selection intends for there to be no auth_events:

The auth_events field of a PDU identifies the set of events which give the sender permission to send the event. The auth_events for the m.room.create event in a room is empty; for other events, it should be the following subset of the room state: [...]

But that rule isn't explicitly enforced in the suite of checks on incoming PDUs.

On the face of it, fixing this by requiring servers to reject m.room.create events with auth events would require a room version bump, because it changes the authorisation rules. But the m.room.create event is special in that it marks the start of the event DAG. Perhaps that gives us some extra wiggle room.

Start with the v1.2 room authorization rules, the auth-events selection section, and the checks performed on receipt of a PDU linked in the issue. Determine whether rejecting auth_events on m.room.create requires a room version change, then update the relevant specification rules and document the resulting behavior.