Reduce confusion between topological and stream position tokens (SPEC-268)

The client-server API has two types of position identifiers, representing two views of the ordering of events:

• topological (tNN-NNN_NNN_NNN_NNN) (aka pagination token)
• stream (sNNN_NNN_NNN_NNN)

A topological position only makes sense within the context of a particular room, and refers to a particular point on the event DAG. The events between two topo tokens are subject to change, as the DAG changes over time.

A stream position is a global identifier across all rooms, and refers to a point on the timeline of when the server received the event (which may be wildly different to where it fits on the graph, or where it happened in a different server's timeline).

/sync returns events in the stream timeline order, and takes a stream position token as a 'since' parameter.

/room/<x>/messages works in the topological timeline order, and takes a topological token as a 'from' parameter.

It's easy to misunderstand what one can do with these tokens. In particular, /sync currently returns:

• next_batch: a streaming token from which streaming can be resumed next time
• rooms.x.timeline.prev_batch: a topological token. The idea is that you can back-populate from here.

We should do our best to reduce the confusion by making sure that we have a consistent set of names which make it clear what sort of token is expected.

(Imported from https://matrix.org/jira/browse/SPEC-268)

(Reported by @richvdh)

Start by reviewing the Client-Server API descriptions of /sync and /room/<x>/messages, focusing on the next_batch, prev_batch, since, and from position tokens. Define consistent names that distinguish stream and topological positions, then confirm the terminology is used consistently throughout the affected specification sections.