Comments / questions on OpenWebAuth V4 #35

No material changes; I've just combined the two "Discovery" sections
into one, and added some headings to separate the protocol into steps.
Also update the "last change" date.

This has implications for the way they are cached.

This is an opaque value which is provided by the target instance when
it does the initial redirect, and is reflected back to it in the token
request and in the final redirect.
This allows it to do two things:
- Positively identify which active login flow is responsible for each
 token request. This makes the data structure management a bit simpler
 for applications like mine which fetch the AP actor record up front
 rather than from the token endpoint; this will also allow me to reject
 any token requests which come "out of the blue" rather than being
 triggered by a previous request to the protected resource URL, which
 makes me feel a bit more comfortable even though I'll admit that I
 don't have a specific attack in mind
- Identify which active login flow is responsible for the subsequent
 request to the destination URL. This allows me to use a single
 destination URL for all OWA flows, meaning that only that endpoint
 needs to be able to handle the "owa_token" parameter; I can use the
 "owa_state" to look up the active flow and find the user's original
 destination URL. This is also possible by embedding the state
 parameter into the destination URL rather than providing it
 separately, but as I mentioned above, it would be convenient to have
 it present in the token request too.

It's a bit of a departure, but it saves a round trip and offers a bit
more flexibility about what information is provided.