URL refactoring

[ml31415]

The current URL implementation did quite some parsing, which is nowadays already done in a more robust and clean way in the standard library. This PR preserves the previous URL interface, while leaving all the actual work to urllib.parse.urlparse and urllib.parse.ParseResult.

It would be debatable, if we shouldn't drop the url module entirely and just use urllib.parse and all tools within directly without any wrapping. Mb something to keep in mind for a potential future major version bump.

[cyberw]

I guess what we lose from this change is the slots-optimization? Dont know if it matters…

[ml31415]

Not really. The ParsedResult is a namedtuple, i.e. "slots". The benchmarks are not impacted anyways, as these URL operations, very unlike the header parsing, are not a bottleneck.

I had initially tried to directly derive from ParsedResult, avoiding this indirection, but that fails, as I'd have had to change the constructor syntax, like Url.from_string(...) or smth. Or def URL(...)as constructor and ParsedURL() as result. Anyways, all of it would introduce breaking changes.

[cyberw]

Lgtm