Moving email-related fields to the root

[stuartpb]

As described in https://github.com/opensets/domainprofiles/issues/135#issuecomment-258744376:

Should password.reset.flow.response.email then be moved to email.password.reset.flow.response, which would open the door for, say, email.login, continuing the metaphor of channels-and-factors-being-off-the-root (and well-accomodating the recent refactors post-#127/#128, and how this data is profiled)?

I think this is solid (it better reflects the general design of the rest of the schema), and I'm going to take a little time to check what any other instances of email-related fields are, and then I'm going to push this as a refactor.

[stuartpb]

Definitely echoes #31

[stuartpb]

Actually, after giving this a little more thought, I'm declining it.

While I'm not opposed to a general email root object that may describe how the domain handles email generally (for instance, a general email.from may at some point in the future be defined as a general-case fallback for password.reset.flow.receive.email.from when the same address is used for, say, sending email notifications), I think things like this that entail a specific case's use of something like email should remain children of that case, rather than a reentrant sibling.

totp and password and thirdparty.auth are all used by login, but they are (theoretically, at least) not strictly tied to login, the way that the fields of password.reset.flow.receive.email are tied to password.reset. For instance, all the fields of password for Github also apply to the password as used for re-authentication, which is separate from login.

For one strength of this, it makes it so the "default case" described in #134 entails a little less spooky-action-at-a-distance, requiring a look at just the other children of password.reset.flow.receive, instead of a bunch of password.reset.flow.receive children off of various objects on the root.

[stuartpb]

I think this can be closed, going back to #135.