refs #127

This is sometimes useful when we don’t want to modify the global page
navigation state, but want to use independent lists.

This should make the API functions more accessible for callers as there
won’t be any loose undefined values that were sometimes needed to skip
certain values in certain API endpoints.

Instead, every positional argument is now required and all configurable
options or extensions are part of the options object.

Using the ID type makes type errors more likely because we accept a
wider range of types as arguments for API operations than we actually
support on a logic level, i.e. when using maps because

	Map<ID, T>.get('1') !== Map<ID,T>.get(1)

Sometimes we want to query the API for certain objects. We can now do
that by passing a URLSearchParams object to list operations.

All requestInit arguments could have been undefined already, because we
declared it as an optional argument, but sometimes it’s nice to
explicitly skip the argument with `undefined` which is now possible as
well.

Pinia store destructuring doesn’t work on the plain store object. One
has to use storeToRefs or keep the original store object.

see: https://pinia.vuejs.org/core-concepts/

refs #146

Django rest framework would sometimes return objects like this

  { "email": ["Gib eine gültige E-Mail Adresse an."] }

which we didn’t properly handle.

The useServerErrors function returns an object with optional keys. This
is fine sometimes but it would be nice to have individual variables
containing errors for each field and more importantly we need to display
errors than cannot be mapped to an individual form field.

Using a string key begs for conflicts.

API object attribute names are now:

1. camelCased (#164)
2. use Id / Ids suffix for object references (#172)

This can be used in views to parse the error state from steering
responses.

We have properties like header, that contain objects that need to be
merged recursively.

We sometimes will want to use these in instanceof checks to narrow down
types so they should have been exported in the first place.

The type for new or updated data rarely is the same as the one returned
from the API as the data will likely include readonly fields that should
not be modified.

The cached result is usually sufficient and we don’t necessarily need
fresh data from the API.

API store consumers shouldn’t be able to modify the internal state of
the store.

Not all API endpoints will have the same behaviour. Some may only allow
updates but can’t remove items, others will use a paginated result list
instead of a plain result array.

Sometimes it’s nice to let the URLBuilder build other URLBuilders.