Now with fixed zoom level for the hunting.

This is a very basic idea, the downside is that you basically cannot
"fix" the tilehunt overlay to a specific zoom level. It might be nice to
get a second renderer that renders the tile hunt for a fixed zoom, and
then adjusts the output tiles accordingly (then it also takes more space
again though).

This is in prepration for the tilehunt mode, where we want to render
tiles differently.

Since we want to support SQLite at some point, it makes sense to have
the exact storage method abstracted away.

This is another pretty CPU bound task (parsing the XML files), so it
makes sense to parallelize. We already have rayon, we already have the
setting to control parallelism, so let's use it and make hittekaart
fast!

This is a bit more DRY, as we only have one place where we need to list
all submodules. It does not give us the "unused function" warning
anymore, but we can maybe find a different solution for that?

It seems like this does not make the encoding slower, and the main point
is that we might want to support SQLite storage for the tiles, in which
case it might be good to have only one writer. Even with the FS-based
approach, maybe it's good to have a single thread responsible for
writing everything, and not hammer the OS with 16 write requests at
once.