Registration v2 improvements (SPEC-274)

v2 registration in its current form has the following problems:
- We don't allow servers to enforce orderings between stages (eg captcha before email)
- We don't uniquely identify stages with distinct params (eg `m.login.oauth` for Google vs Github)
- We don't allow users to submit multiple stages at once.

I had a nice chat with eternaleye about some of these issues and the main points were:
- We can't enforce captcha before email full stop because the email sending step is done directly by the client to the IS, which has no knowledge of registration flows.
- For stages which have side effects (like sending an email), you really have three options:
- Eager sending with whitelists. Clients tell the server "I can do these stages". When the server sees that pre-requisite stages are complete AND the client can do the side-effectful stage (e.g. `m.login.email.identity`) it eagerly sends the email / does the side effect knowing that the client will be able to do the whole thing.
- Two-step (one step to trigger the side effect, one step to fulfil it). There's no additional RTT costs since side effects inherently involve an extra RTT (e.g. do stuff > side effect > do more stuff)
- Externally done (but you lose any ability to do ordering).
- Each stage should really have an opaque `id` to distinguish between the **same type** with **different params** (E.g. oauth type hitting Google vs Github) which is sent up to the server.
- The value of having `params` at the top-level separate from its stage is questionable and in its current form (where this consists of keys with the stage type) don't actually allow you to do the Github vs Google case because you'd clobber `params["m.login.oauth"]`. Suggestion was to tie params with the actual stage rather than be top-level e.g.

```
flows: [
[
{
type: "m.login.oauth2",
id: "sth",
params: {
url :"http://google.whatever"
}
}
]
]
```
- We should allow clients to submit multiple stages at once. This could be done using an auth dict like:

```
"auth" : {
"session" : "xxxxx",
"fulfills" : [
{type: m.auth.login, id: "abc", ...},
{type: .... }
]
}
```

For this to play nicely with ordering, servers would hold back processing later stages even if they have received the data from the client until all previous stages are done (e.g. stages [A,B,C], client submits A,C, only A is processed since they haven't done B yet).

Proposed actions:
- Swap to an `id` system with coupled `params`.
- Allow clients to submit multiple stages at once (e.g. with a list of auth dicts).

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

(Reported by @Kegsay)

Start by reviewing the proposed actions and the discussion in this issue, focusing on stage IDs, coupled parameters, ordering, and submitting multiple stages. No implementation files or tests are identified in the issue; done would require an agreed protocol design and corresponding specification changes.

Written by the indexing model from the issue text.