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.