Sharpen remote definition

[chrysn]

With #224 being addressed, and the parallel work with group OSCORE, the purpose of remote seems to become a bit clearer -- but that does need to be expressed in the docs.

• A remote always needs to be there, but it can be very unspecific.
• The context (or the transport) may switch around the remote if they can show that it's OK. For example, the protocol will replace the maximally-unspecific UndecidedRemote with a concrete transport's remote (because "anyone" includes the responder), or a response to a group request will come from a pairwise remote (because that's how group OSCORE works).
• On the high level, client applications should preferably pass in URIs and not bother with remotes; this makes switching over to a new TCP or DTLS connection trivial when a single request failed. (The library generally can't spare the application the handling of the high-level retransmission because the operation may not be idempotent).
• An application may want to check for remote equality in some situations or even set the remote manually if the request needs to go on the very same channel (eg. in blockwise follow-ups or when using echo manually); in those cases it needs to be prepared to on its own stop using a remote that started producing errors, and backtrack to whereever it's safe to start again.

[chrysn]

As of removing some comments on this topic from the DTLS transports, a client may also want to use a method on a remote like "give me a remote to the same location but a bit relaxed, like do the name resolution again or build a new security context if you need it". It's not certain yet if there's any benefit to this over just putting in the original hostinfo into an UndecidedRemote and letting the specialization process run its course.