Improve the description of the rules for relative NOR requests and add examples

[wilaw]

[From Chris Lemmons]
Relative path resolution is defined in https://datatracker.ietf.org/doc/html/rfc3986 (which, in retrospect, we should have cited).

The way relative paths are merged is defined in 5.2.3. Relevant here:

o return a string consisting of the reference's path component
appended to all but the last segment of the base URI's path (i.e.,
excluding any characters after the right-most "/" in the base URI
path, or excluding the entire base URI path if it does not contain
any "/" characters).

So, the following prefetch uri should work:

y.mp4
./y.mp4
/a/b/y.mp4

These are legal, but go to the wrong place:

b/y.mp4 will go to https://example.com/a/b/b/y.mp4
../y.mp4 will go to https://example.com/a/y.mp4
../../y.mp4 will go to https://example.com/y.mp4
/y.mp4 will go to https://example.com/y.mp4
/b/y.mp4 will go to https://example.com/b/y.mp4
/a/y.mp4 will go to https://example.com/a/y.mp4

We probably should have cited the URI spec to indicate where the relative path goes, but since that’s how HTML uses it and browsers expect it, I suspect the RFC’s definition will match people’s intuition. And there’s a very tiny technical nit (that we should fix) because the RFC defines the base URI relative to the representation request URI and in our situation, this is part of the request itself, not the representation being responded with. Still, I think it’ll match the intuition.