`creators` is still missing, as it is an array and Meili does not allow
to retrieve the exact match position there yet.

The `id` field that was requested for all items unfortunately made
the types worse. By just requesting it individually for each item,
we get better types and can get rid of lots of boilerplate code.

I will use this in an upcoming commit, and it also seems like an obvious
addition, given our other video/series routes.

- We now always show 3 items, regardless of how many videos the series
  has.
- This means sometimes dummy elements are shown, which use some CSS
  pattern.
- The outline is wider and has a stronger color now.

The "3 things behind one another" shape/image is an important pattern in
our design language to mean "series". These changes make it more
consistent and thus recognizable.

This contains a bunch of changes! I will just list the major ones:
- The thumbnail is now left, the description on the right. This goes for
  all result types.
- Realm results have an icon instead of a thumbnail(-stack), but the
  "result type" icon that all results had is gone now.
- The three result types are now visually more distinct to be able to
  distinguish them at a glance. The info-section is still fairly
  similar, but the "image" section (left) is very different.
- Series & Videos that only have a single host realm now show the realm
  path. Further, series with a single host realm now link to the series
  inside that realm instead of the direct link.
- The result items don't have a border anymore.
- For videos, the date is shown.
- Thumbnails of video results are now bigger.

When `prefix` was empty, it would result in twice the same key.

…ain search

This shows how long each step in the search "pipeline" takes. This helps
to optimize for faster "search as you type" searches. Typically we don't
commit such debugging code, but this might be useful for a while, to
constantly have a look at the timings. Will very likely be removed some
time in the future.

Somehow we did an oopsie and added a second debounce for searching. But
there is already a 30ms debounce! This added lots of delay that the user
notices in a bad way. Of course, less debounce means that the server is
potentially stressed more. But I think this is still absolutely fine.

Profiling rendering showed that those match timelines are very expensive
to render. We deferring the rendering, the whole route can be rendered
quicker. A difference of 100ms was quite normal. Also, only timelines
inside the viewport are rendered, which is good for "search as you type"
as most result lists are not viewed by the user at all.

Turns out we cancelled the debounced function (that starts the search)
on unmount. I am not sure why we did that. This is just `setTimeout`,
not `setInterval`, so the function is just called at some point and then
the whole thing is over. No need to clean up anything.

The problem with this was that a change in the input field called
`setTimeout(search)`. But this timeout could be cleared by a previous
render-unmount, so that the last letter, for example, might be ignored.

This is mostly due to feedback by our designer. I changed these things:

- Distance between search result items increased (slightly in desktop
  mode, quite a bit in mobile mode).
- Font size of date, creators and series title (all in video results)
  reduced to 12px, the same as the description. Fewer different font
  sizes in the results, and makes everything a bit less crammed.
- Hover-effect of search result now has a short transition to make it
  feel smoother.
- Increase max-width of whole page so that results can be a bit wider
  on wide screens (900 -> 1000)
- On screen widths between 470 and 650, make the video info as wide as
  the thumbnail and center it. Having the info span the full width, when
  the thumbnail is centered does not look great. Sure, this wastes some
  screen space, but the max width 400 is still more than the info is
  wide at screen width 651.

Also as a result of talking to our designer. She thought that a neutral
grey would be fine to highlight results. Sure, yellow-ish is learned
as "text marker" color, but it should likely be clear anyway.

However, this point is certainly up for debate. Will comment in PR.

This makes it so that the header elements are retained over route
changes, so for example focus is not lost on the search input field, as
the actual DOM node stays. Previously, the complete header DOM was
recreated.

I really hope this change has no unforseen consequences. See comment for
why this hack is even necessary.  Also see
d5f34dd

When leaving the search route by clicking on a result, the search mode
is closed, i.e. the normal header is shown. On the search route,
the menu is always in search mode (on narrow screens). We figured that
if users want to get to anything else in the header, they would
intuitively press the arrow-left or the X and get what they want.