ObjFW  View Ticket

Currently, `OFURL` only supports, as the name implies, URLs. However, it would be nice to also be able to handle URIs. As it would be bad to have two classes, the best way forward would be to rename `OFURL` to `OFURI` and add URI support as per 3986 to it.

It seems the main changes needed would be:

* Rename to `OFURI` and change `OFURL` -> `OFURI` everywhere
* Drop `fragment` entirely
* Add support for parsing URIs with no authority, making `host`, `port`, `user` and `password` `nil` when there is no authority.

As this is breaking the API, this needs to happen before the 1.0 release.

This raises the question: What to do with `OFURLHandler`? Will it become `OFURIHandler`? How would a URI be handled? Is it desirable to handle a URI? Would `objfw-embedded:///some_file` become `objfw-embedded:some_file`?

URLs know how to locate something, but URIs don't. But theoretically a handler could even know how to retrieve it without a location, hence `OFURIHandler` would make sense?

Renaming `OFURL` to `OFURI` has been done in [](e7ab06503c).

Dropping fragment was obviously a brain fart. What I meant was dropping `parameters`, but those were already dropped before. I shouldn't write tickets when tired.

Some more things that should be changed:

* Normalization should strip leading `.` or `..` from paths. RFC 3986 specifies that a path of `/../foo` should be normalized to `/foo`, see [section 5.4.1](https://www.rfc-editor.org/rfc/rfc3986#section-5.4.1).
* An empty authority should lead to an empty host and not a `n``l host, as a nil host would mean no authority.
* The `file:` scheme should treat no authority the same way as an empty authority as per [RFC 8089 section 2](https://datatracker.ietf.org/doc/html/rfc8089#section-2).
* Since `file:/some/path` is nicer to read to `file:///some/path`, it can be considered to switch using no authority instead of an empty authority when using `fileURIWithPath:`.
* Since the `objfw-embedded:` scheme is not really hierarchical, it should be changed to not use an authority and not start paths with `/`, so that it can be treated as opaque.

URI parsing is now implemented ([](c75059a52f)), as well as not using `nil` when the host is empty.

However, parsing of relative URIs is not according to RFC 3986 yet.

* `file:` and `of-embedded:` (new name for `objfw-embedded:`) didn't need any changes to accept URIs without an authority, so they just work in the desired way.
* URI differentiating between empty and `nil` host automatically made it create file URIs without an authority (`file:/foo` instead of `file:///foo`).

This means only the normalization and handling of relative URIs needs to be changed to comply with RFC 3986.

Relative URIs as per RFC 3986 have been implemented in [](3b2697b2a7). This completes URI support.