[API CHANGE] Adapt css.uri UNOIDL entities to RFC 3986

[Stephan Bergmann]

I'd like to draw your attention to the planned URE API change 
<https://gerrit.libreoffice.org/#/c/77861/> "[API CHANGE] Adapt css.uri 
UNOIDL entities to RFC 3986".  The original implementation of 
css.uri.UriReferenceFactory et al was based on then-current RFC 2396 
(<https://tools.ietf.org/html/rfc2396> "Uniform Resource Identifiers 
(URI): Generic Syntax"), but which has long since been obsoleted by RFC 
3986 (<https://tools.ietf.org/html/rfc3986> "Uniform Resource Identifier 
(URI): Generic Syntax").  Conformance with the new RFC required some 
changes in behavior of those UNOIDL entities, mostly around corner 
cases; for details see the list below, extracted from the commit message.

If there is no objections over the coming days, I'm going to push this 
to master soon.


> * XUriReference.isHierarchical is obsolete and deprecated.
> 
> * The behavior of XUriReference.hasAuthority, XUriReference.getAuthority,
>   XUriReference.getPath, XUriReference.hasRelativePath,
>   XUriReference.getPathSegmentCount, XUriReference.getPathSegment,
>   XUriReference.hasQuery, and XUriReference.getQuery has been made consistent
>   for all URIs, no matter whether they were considered hierarchical or opaque in
>   the past.
> 
> * The behavior of XUriReferenceFactory.makeAbsolute and
>   XUriReferenceFactory.makeRelative has been changed to match the RFC 3986
>   reference resolution specification.  The XUriReferenceFactory.makeAbsolulte
>   parameter processSpecialBaseSegments has been renamed to
>   processAdditionalSpecialSegments, as per the updated specification it now
>   controls treatment of special segments in the given uriReference, in addition
>   to special segments in the given baseUriReference.  (Renaming UNOIDL interface
>   method parameters is technically an incompatible change, but the benefits of
>   improved clarity presumably outweigh any potential drawbacks in this case.)