Fails to build with Qt6 otherwise.

This removes a lot of now obsolete timezone and country lookup code and
data tables.

This duplicates a bit of code we can remove again once we depend
unconditionally on KF 5.88. Doing this now already however allows
for an easy side-by-side comparison of the results.

There are minor changes in places with ambiguous timezones, and
since country lookup is no longer tied to timezones, we now also
get proper results for Thailand and northern Vietnam.

This should now allow switching out the implementation without having to
touch the consumers, and there's no remaining use of implementation
details on the outside.

Allows us to drop yet another function we wont need with KI18nLocalData
from the interface.

Another step towards porting to KI18nLocaleData.

timezoneForLocation() handles that just fine.

This reduces leaking the internal timezone enum out of the knowledge db
code, which helps with the port to KI18nLocaleData.

This is meanwhile done more generically in the post-processing code.

This is now possible that Wikidata got that information, and enables for
example Thalys barcodes to be matched to the correct stations.

This also includes a bit of refactoring of the station identifier db
generation to get rid of some of the code duplication there.

This is now provided by the generic geo coordinate based timezone lookup.
This also contains an update to the SNCF station code index to cover
international destinations as well.

Should fix the build.

SNCF station codes a strict superset, and also cover e.g. foreign stations
not managed by Gares & Connexions, and thus is what we actually want here
to make international tickets work as well. This only recently became
available in Wikidata though.

This does not contain the actual db update yet, that will happen as part
of the removal of the explicit timezone information.

That enables the coordinate-based lookup functions for timezones and
countries.

This will also allow the removal of the timezone columns in the airport
and train station tables down the road, saving some space there.

That's Asia/Bangkok which is also used in northern Vietnam since the 2019
timezone shapefile release, and Europe/Simferopol which is a disputed area.

This is largely unique, and should allow us to improve the result for the
coordinate-based timezone lookup when having a country context.

That was at least the initial motivation, however it looks like this might
eventually allow us to build a coordinate -> country mapping as well,
without needing an extra spatial index.

So far this were offsets into the the IANA string table, now it's a flat
enum. The old way needed 13 bits per record, the new only needs 9 bit, at
the cost of an extra ~800 bytes for an offset table to get back to IANA
names. This however quickly pays of when storing large quantities, which
we do (~37k in the current database, more in the upcoming experiments for
an efficient geo coordinate to timezone mapping).

This doesn't cover codes containing 'Ä' or 'Ö' yet, which appear in the
official list, but for which we have no idea how they are encoded in the
corresponding barcode yet. As that's only a dozen or so in total, that's
not a big problem though.

This will replace the implementations of IataCode and CountryId, and avoid
the code duplication in the now also needed 3-letter country code table.

This reduces the size of the station id tables by 25%.

Our previous naive approach introduced an error of about 10km, which is
significantly larger than the resolution of the timezone image (1.5km),
and is actually relevant for densely populated areas close to timezone
borders, as well as small islands (as our search radius for those is
just 5km).

Worth it, as it increases coverage for countries with 1.4+B inhabitants.

Not perfect, but it's a very cheap solution for all but about two dozen
countries where this is a bit more complicated.