Distinguish 'client' from 'federation' events (#3658)

Fixes #3305 
Fixes #3380
 
The idea here is to better distinguish between a 'raw' event (as we send over the wire), and the 
'serialised' format, as sent in responses to the C-S api and in `PUT /_matrix/app/v1/transactions/{txnId}`.

It's made more complicated by the fact that there are _two_ serialisation formats, one used by `/sync`
and `/notifications`, and one by everything else (the difference being whether `room_id` is included).

In an ideal world, we wouldn't repeat `SerialisedEvent` every time it's used, and instead just link to the
first reference, but that's a job for another day.

Another job for another day is to get rid of things like `sync_state_event.yaml` (which is now used
only in one place, so should be inlined.)

data/event-schemas/schema/core-event-schema/unsigned_prop.yaml

@@ -18,31 +18,5 @@ description: Contains optional extra information about the event.
 properties:
   age:
     description: The time in milliseconds that has elapsed since the event was
-      sent. This field is generated by the local homeserver, and may be incorrect
-      if the local time on at least one of the two servers is out of sync, which can
-      cause the age to either be negative or greater than it actually is.
+      sent.
     type: integer
-  redacted_because:
-    description: The event that redacted this event, if any.
-    title: Event
-    type: object
-  transaction_id:
-    description: |
-      The client-supplied transaction ID, for example, provided via
-      `PUT /_matrix/client/v3/rooms/{roomId}/send/{eventType}/{txnId}`,
-      if the client being given the event is the same one which sent it.
-    type: string
-  prev_content:
-    description: |
-      The previous `content` for this event. This field is generated
-      by the local homeserver, and is only returned if the event is a state event,
-      and the client has permission to see the previous content.
-    x-changedInMatrixVersion:
-      1.2: |
-        Previously, this field was specified at the top level of returned
-        events rather than in `unsigned` (with the exception of the [`GET
-        .../notifications`](/client-server-api/#get_matrixclientv3notifications)
-        endpoint), though in practice no known server implementations honoured
-        this.
-    title: EventContent
-    type: object