Implement URI structure modularity (or fix its hierarchy).

Is your feature request related to a problem? Please describe.

Currently, contact URIs are structured like https://example.com/apps/contacts/All%20contacts/e1f2ec5c-074e-4575-ac62-53ff24770ffb~contacts. This isn't very extensible, nor is it humanly parsable.

Describe the solution you'd like

Something like https://example.com/apps/contacts/All%20contacts/?address_book=contacts&contact_GUID=e1f2ec5c-074e-4575-ac62-53ff24770ffb:

• The ordering is deliberate because it retains the logical hierarchy, although it obviously isn't important due to how all arguments of a URI are parsed in their entirety before they are consumed.
• Compartmentalisation of each segment also provides some redundancy - in case the address book cannot be found, the interpreter can more easily understand that it needs to search for the relevant contact.

Describe alternatives you've considered

https://github.com/nextcloud/tasks structures its URIs like https://example.com/apps/tasks/#/calendars/3de72895-d345-4ac4-8eec-1418e857ba7e/tasks/B1597847-EB92-49A0-84C8-9B4E91CC8068.ics - a simple hierarchy. This is obviously more brittle, but generally acceptable. I don't know why you'd do it like this though when you're not directly interacting with a filesystem - it's all abstracted enough that we can use non-hierarchical structure to provide more flexibility.

Additional context

Don't consider backward compatibility yet, because your current system provides little. After this or another similar implementation that I haven't considered has been implemented might backward compatibility become worth the struggle.

No files or tests are named. Start by locating the contact URI construction and parsing entry points, then compare the current path-based structure with the proposed query parameters. Done means an agreed, implemented URI hierarchy or modular structure that supports contacts and address books without relying on the current concatenated format.