* 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
* in the JMAP API as well as in several places in the Groupware
framework, use a single jmap.Response[T] object to return the
payload, the language, the session state and the etag/state instead
of individual multi-valued return values
* the "position" attribute is always set to 0 when using an anchor for
pagination, but it does not accurately reflect the position and thus
we decided to remove the attribute from the resulting object for
clarity
* omit "canCalculateChanges" attribute when its value is "true", which
is going to be the case in 100% of calls against Stalwart
* JMAP query limit of 0 is synonymous with "no limit", but we actually
want to be able to perform queries without any results, for cases
where we only want to count the total number of objects, and also
because it makes more sense semantically
* introduce query parameter validation checks, in order to only allow
query parameters that are actually supported, which is going to be
useful during development of clients
* make the JMAP internal API a bit more future-proof by passing
ObjectType objects instead of the JMAP namespaces
* remove the new attempt to contain operations even further using the
Factory objects
* move CalendarEvent operations to its own file, like everything else
* fix email tests
* ignore WS error when closing an already closed connection
* add Groupware APIs for creating and deleting addressbooks
* add Groupware APIs for creating and deleting calendars
* add JMAP APIs for creating and deleting addressbooks, calendars
* add JMAP APIs to retrieve Principals
* fix API tagging
* move addressbook JMAP APIs into its own file
* move addressbook Groupware APIs into its own file
