Listener-Offerer flow

[stuartpb]

Yet another rearchitecture to match unwritten rules about how WebRTC is meant to be used:

• First step for a client: POST to the phrase URL.
• If the response is 201 (first end), start listening at the given location.
• The server drags the internal UUID and connects it to the next POST.
• If the response is 302 (second end), start listening, and create an Offer that you POST to the location as well.
• First end gets the offer and POSTs an answer.
• ICE escalation happens as it did previously.

If the second end doesn't end up POSTing an offer, the original end will 404 once the created connection times out, which is why it's acceptable for the second responder to declare itself after the connection is created (and not required to do it with the connection or something like that). The end will need to restart (re-POST).

[stuartpb]

Thinking about it now, the one-side-awaits-messages-and-the-other-side-can-connect-without-sending-one paradigm isn't working for me. It means I have to make it so that one end's GETs don't refresh their non-messages, but not the other; at that point I feel like I might as well be sticking with Offers, but allow the Offers to be empty (but not the Answer, so the Answer becomes the actual Offer and Offer becomes a Request for Offer).

I might make a similar clone of Offer like Request-Offer: thinking on it, it could even work, backwards, like the earlier Chatphrase signaling tweak where Offers are always sent, then set as local only if the other end accepted it.