origin_client_ts to distinguish composed v. sent timestamps

**Suggestion**
The intention of timestamp fields on events was always to distinguish timings clearly across the lifecycle of a message being sent: when the send button was hit (origin_client_ts); when it was received by the server (origin_server_ts); and possibly unsigned data for when it was delivered to the destination server (dest_server_ts); when it was received by a given destination client (dest_client_ts).

Historically, clients tended not to automatically flush their send queues, and so the user had to consciously interact when flushing the queue - meaning they could remove stale messages and psychologically were effectively "hitting send again" in order to send them. Therefore origin_server_ts was an adequate timestamp for the sent msgs.

Nowadays however, clients like matrix-rust-sdk automatically flush send queues in the background, meaning that clients send messages with arbitrary origin_server_ts which don't reflect when the user consciously intended a message to be sent. Therefore, we need to (at last) introduce origin_client_ts to distinguish the two, letting clients display timestamps based on when a message was created rather than when it happened to get received by the server.

See https://github.com/element-hq/element-meta/issues/2678 for more details.

Begin with the timestamp lifecycle described in this issue and review the linked Element issue for context. The work is complete when the Matrix specification has an agreed definition and placement for origin_client_ts, including how it differs from origin_server_ts and other delivery timestamps.

Written by the indexing model from the issue text.