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

Interfering with the default dialog close logic isn’t that smart because
it handles stuff like nested dialogs for us.

We need to find some other logic to close the dialog when someone clicks
on the backdrop, but that can be a task for a later time.

Using the same name as the native HTML dialog is a bad idea.

refs #89

closes #139

closes #138

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.

This should make it easier to find icons, as they can now be included
directly as component:

<icon-... />

Icons can be found on: icon-sets.iconify.design

Example:
Icon at https://icon-sets.iconify.design/ph/trash/ can be used with the
following component:

<icon-ph-trash />

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.

refs #89

We don’t want to show schedules that are in the past because they
clutter the overview.

refs #120

Schedules that only run for a single day should display when that day
is.

refs #121

closes #133

The tests could fail if some environment variables were already set or
if the tests have already been executed.

We’ve decided to move the show selector into the navbar because the
selected show is the primary state of the dashboard from which almost
all other state is derived.

Apart from that we now have support for filtering the list based on
active and inactive shows (and possible other criteria in the future) as
it was suggested in #122.