Clarify what makes using m.* wrong, and what a server should do with events created in that namespace

The top-level spec introduction https://matrix.org/docs/spec/#events says

> The special top-level namespace `m.` is reserved for events defined in the Matrix specification.

But as far as I can tell, the spec does not clearly say what a server should do if it:

1. Receives an `m.*` event from a client that is not part of the client-server API that the server supports.
2. Receives an `m.*` event via federation that is not part of the client-server API that the server supports.

The closes the spec comes might be the [federation API](https://matrix.org/docs/spec/server_server/r0.1.4#checks-performed-on-receipt-of-a-pdu) "Checks performed on receipt of a PDU" which says

> The receiving server must ensure that the event... is a valid event, otherwise it is dropped.

But then does not go on to say precisely what is considered valid and invalid.

### Potential kinds of invalidity

I was thinking of these kinds of invalidity:

1. The `m.*` event isn't part of the client-server API. Rejecting these could mean rejecting events that are valid in a future version of the spec.
2. It's part of the client-server API, but is missing required fields. It seems sensible to always reject these.
3. It's part of the client-server API, but includes extra fields (on top of the optional fields that the spec allows).

Start with the top-level spec introduction and the federation API section, especially “Checks performed on receipt of a PDU,” then compare their rules with the three cases described for m.* events. Done means the specification clearly defines which events are valid and what servers should do for unsupported, incomplete, or extra fields.

Written by the indexing model from the issue text.