This is helpful if multiple operations should use the same error object.

refs #181

* can now be used to represent date, time and datetime strings
* does support nullish-values with proper types
  (and adds a corrosponding default value)
* allows timezone offset to be stripped for use
  in datetime-local input fields

This refactors the existing state helpers (useCopy and
useUpdatableState) and unifies them to useUpdateBehaviour, useCopy,
useAPIObjectFieldCopy, useRelation and useRelationList. This eliminates
a lot of custom code in the show settings page and unifies the behaviour
of all input fields and save operations making the experience more
consistent and understandable.

It also enables us to show the save-in-progress state and errors that
occurred during updates for all fields along with customizable debounce
and proper v-model support.

We also got rid of the remaining uses of useSelectedShow. The show
settings page still made use of it despite using a route that
provides the relevant show that should be edited.

refs #127

refs #191

refs #146

Duration strings may return an awkward format if the seconds it is
calculated from were fractional. A single second is the maximum
precision we want for a duration string so we can simply round them in
order to avoid such cases.

refs #155

refs #151

refs #126

Users weren’t able to create a time slot in the calendar if the slot
has already begun.

The logic now checks if the start time is later or equal to the start of
the slot of the current time (i.e. current time is 16:37:28, check is
performed against 16:30:00 for a 15 minute calendar slot size). This
prevents users from creating slots in the past but allows them to create
time slots within a slot that has already begun.

If the slot has already begun then the start time of the new time slot
is set to the next available 5 minute slot after the current time. This
means that if the current time is 16:37:28 and one creates a time slot
in the 16:30:00 - 16:45:00 slot window the start time of the new time
slot is set to 16:40:00.

fixes #167

isProcessing seems more general purpose as it’s not clear if the
provided function actually loads something.

As we wrap an async function we must await it. Otherwise finally is
called immediately.

closes #139