More details around password.reset.flow.open handling

[stuartpb]

This touches some discussion in #37 (especially #37 (comment)), #70, #120, #127, and some of the design considerations relating to the fields of #130: the details of how password reset flow links work, beyond just expiration point, are important enough to be documented in more detail:

• What's the format of reset URLs? Is there only one URL, on which you input a token? (Especially if the out-of-band signalling channel isn't email - especially a phone call).
• Does opening this link / token redirect you to a new page? What kind of redirect is it? Does that page have remnants of the token in the URL? (This is important: see https://robots.thoughtbot.com/is-your-site-leaking-password-reset-links)
• Is there a POST step (even just a "click this button") before burning the open token? (If just GET can burn the token, that's technically a REST violation.)

Of course, these questions don't map 1:1 to fields, but they have associated use cases for which it'd be practical to answer.