* refactor APIs in JMAP and Groupware in order to implement pagination
across multiple accountIds and multiple suppliers (currently
implemented using a mock supplier for contacts)
* requires go 1.26 due to use of self-reflecting generics type
constraints
* still missing: query criteria and sorting parameters
* still missing: multi-accountId support for emails
* errors are now all just 'error' in the APIs, instead of the
specialized implementations, and are interpreted dynamically where
necessary in order to transform them into HTTP responses
* remove position, anchor, anchorOffset as individual query parameters
as we now only support a 'next=...' token for subsequent pages
(except in emails for now), and use jmap.QueryParams instead; those
tokens have a header character for the format, followed by a JSON
encoded QueryParams map, all wrapped into base62 to make it clearer
that it is meant to be an opaque token, and not a parameter clients
should tinker with or construct themselves
* introduce QueryParamsSupplier as an interface to provide QueryParams
for various scenarios (single supplier, multiple supplier, ...) per
accountId
* implement multi-supplier template methods slist and squery
* re-implement the auth-api service to authenticate Reva tokens
following the OIDC Userinfo endpoint specification
* pass the context where necessary and add an authenticator interface
to the JMAP HTTP driver, in order to select between master
authentication (which is used when GROUPWARE_JMAP_MASTER_USERNAME and
GROUPWARE_JMAP_MASTER_PASSWORD are both set) and OIDC token
forwarding through bearer auth
* add Stalwart directory configuration "idmoidc" which uses the
OpenCloud auth-api service API (/auth/) to validate the token it
received as bearer auth from the Groupware backend's JMAP client,
using it as an OIDC Userinfo endpoint
* implement optional additional shared secret to secure the Userinfo
service, as an additional path parameter
