Add check_date support

[eisams]

Does two things:
Imports check_date to the map generator
Displays the contents of check_date on POIs

Open questions:

• What kind of validation should be done? Likely only wish to include this in the map data if it's formatted as YYYY-MM-DD, and I think the map generator has functionality for validation?
• What's the minimal useful presentation of the information?

Related to #7882 #7036 #6811

[RedAuburn]

it'd be good to whitelist what types it's added to (amenity, shop, craft, leisure, office etc keys. There may be others).
Otherwise there'll be lots of things like telephone poles, trees, bins with check_date. Which imo isn't useful enough to store

[RedAuburn]

also please use DCO, put Signed-off-by: Full Name <email> in each commit description :)

[pastk]

• What kind of validation should be done? Likely only wish to include this in the map data if it's formatted as YYYY-MM-DD, and I think the map generator has functionality for validation?

I don't recall seeing it, but it might exist :)

• What's the minimal useful presentation of the information?

I think an exact date is not needed. It might make sense for mappers, but for the most users it'll be just confusing.
Something like "This POI information could be outdated or it might not exist anymore" is enough IMHO.

Hence as @Zverik has rightly noted in #7036 (comment) a boolean "outdated" flag might be enough.

What if the map file is very outdated on user's device?
Logically we kinda should note it for every POI then, but it doesn't make sense and will be annoying :/

[biodranik]

Would it be better to avoid complicating the generator (and increasing the map file size) and implement this as an optional online feature? What are the pros and cons?

[eisams]

For context there are ~1 million check_date: https://taginfo.openstreetmap.org/keys/check_date
If I use an online byte calculator, check_date=2024-01-31 is 21 bytes
So 21 MB total worldwide

If OSM get to the ~60 million POIs as in Overture, then we're talking 1.26 GB

(No clue if this is correct, but I'd think this is an upper bound for an inefficient implementation without compression?)

[matheusgomesms]

And if the "this POI might be outdated" is used, then I'm sure the map size increase will be almost negligible.