v2 login flow representation (SPEC-118)

Consider if a tree-only approach is going to be better than using string arrays.

Complete stages:
foo -> bar
  `--> baz

alice -> bob -> charlie

stages: [
  {
    type: "foo",
    stages: [
      { type: "bar" },
      { type: "baz" }
    ]
  },
  {
    type: "alice",
    stages: [
      {
        type: "bob",
        stages: [
          { type: "charlie" }
        ]
      }
    ]
  }
]

@​eternaleye for suggestion:

M-kegan: Well, if "next" can be a list, then the sensible thing IMO is to replace the 'stages' list with a 'stages' tree.
M-kegan: Basically, instead of info: [{type, stages}] where stages: [type], have info: [{type, stages}] where stages: info
M-kegan: And then the absence of 'stages' indicates bottoming out on the auth flow.
M-kegan: Plus, if the next key is also an info (for a subtree), then it can just be treated as recursion in clients.
M-kegan: Also, it being a tree would allow stuff like a client library pruning by the auth methods it supports before returning the info to its caller
M-kegan: I guess part of it is that I feel the different representations may be a source of implementation bugs (especially server-side)
M-kegan: Another benefit is that server-side implementations could actually represent the auth setup as a tree, and just have a serializer to generate the appropriate json

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

(Reported by @Kegsay)

Start by reviewing SPEC-118 and the existing Matrix login-flow representation, then compare the string-array and nested-tree approaches described here. A decision on the representation, its client and server implications, and corresponding specification updates would be needed before this work is complete.