* 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
* jmap: add UpdateContactCard and UpdateCalendarEvent funcs
* use JSON marshalling and unmarshalling into a map for toPatch()
implementations
* add updating ContactCards and CalendarEvents to tests
* add deleting ContactCards and CalendarEvents to tests
* make query response totals work when the value is 0
* tests: use CreateContactCard and CreateCalendarEvent funcs to create
objects in tests instead of using a different JMAP stack that works
with untyped maps