Consider removing the relative-URL distinction in import names

[lukewagner]

Initially I thought it would be useful to keep the absolute- and relative-URL cases syntactically separated, since the relative URL case requires this extra base URL argument which may not be present in various hosts (unlike the browser where there is always an ambiently well-defined base URL). You might hope that absolute-vs-relative would be a simple grammatical distinction, like it is in the original URL RFCs, but it's not (Web reality is much more complicated), which is why I thought it would be nice just to make the distinction clear one level higher. However, one can always invoke the URL parser (say, as implemented by the JS URL constructor) with an empty base URL and see if it fails and apparently this is a common way to ask whether a URL is relative.

Based on this realization from feedback from @rossberg in #276, this PR proposes to remove the distinction at the importname level, instead having all URLs just use the url=<...> case, subsuming and removing the relative-url=<...> case. Note that component-model validation still doesn't require URL parsing (any UTF-8-encoded bytes are considered valid), so it's only once a host wants to actually fetch the URL that the string gets URL-parsed.

That being said, I'd be curious if there are any other considerations for why it's useful to keep the two cases separate that I'm overlooking. My assumption is that this change doesn't impact ESM-integration (which only needs the continued distinction of <plainname> vs. <urlname>), but @guybedford please check me on that.

Practically speaking, since relative-url=s were shipped in 0.2, we'll probably want a deprecation window during which tools can (trivially) switch to url=. It's also possible that noone actually had time to start using relative-url=. CC @macovedj, who may also have thoughts.

[macovedj]

This should be fine for our use cases!

[lann]

I guess my only question is whether this should be called "url" at all, given that "relative URLs" aren't really a well-specified thing outside of certain web contexts. Maybe "location", mirroring the HTTP header?

[lukewagner]

I guess we could say that when we write url=<str>, we're saying "construct a URL given str and an optional base URL according to the Web URL spec". I worry that "location" over-genericizes and invites folks to throw in other totally random strings which then forces platforms to do ad hoc content-sniffing to see what they have. Granted, the Component Model doesn't force str to be URL-parsed as part of its validation predicate (since otherwise the validation predicate would need to take a base URL as a parameter), so maybe this happens anyways, but having "URL" in the name makes it clear that you're not "supposed" to do that.