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/api/client-server/message_pagination.yaml

@@ -125,7 +125,7 @@ paths:
                   are available. Clients should continue to paginate until no `end` property
                   is returned.
                 items:
-                  "$ref": "../../event-schemas/schema/core-event-schema/room_event.yaml"
+                  "$ref": "definitions/client_event.yaml"
               state:
                 type: array
                 description: |-
@@ -138,7 +138,7 @@ paths:
                   sent to the client in prior calls to this endpoint, assuming
                   the membership of those members has not changed.
                 items:
-                  $ref: "../../event-schemas/schema/core-event-schema/state_event.yaml"
+                  $ref: "definitions/client_event.yaml"
             required: [start, chunk]
           examples:
             application/json: {