Codechange: make TimerGameCalendar Date and Year types strongly typed

[TrueBrain]

Motivation / Problem

With #10700 on the horizon, I am a bit afraid we will mix up Calendar with Economy, and get some weird buggy behaviour because of it. So I was wondering: can we make Date strongly typed, to avoid that issue.

This PR is a proof-of-concept for that. Curious what developers think.

And of course, by making it strongly typed, there is no actual functional change. It is just meant to assist the developer in not making silly mistakes. This was already fruitful, looking at all the PRs that came from this PR, with weird mistakes and boo-boos we made in our code-base.

Description

I went for a slightly different approach than TileIndex, as that requires defining a struct. I was more interested in using using to create a new type. Got some inspiration from https://github.com/anthonywilliams/strong_typedef to make that happen.

Initially, I made the conversion to int32 implicit (so it auto-cases to int32 if it wants to). This had as nasty side-result that you could assign a Year to a Date and the other way around. As the compiler, as clever as it is, casted the one first to an int, to assign it to the other. This is kinda defeating the purpose of having strong-types to prevent people mixing up Calendar and Economy.

So, making it explicit is the way to go. Sadly, that showed tons of places in our code where we take some ... freedom in terms of using a date/year to use as integer. The weirdest things. A lot of small PRs came from this to address most of these.

Limitations

Although performance shouldn't be impacted, as this is just compiler-hints etc, it is not a guarantee that there won't be any if used wrongly. Especially when disabling all optimization, some performance degradation is to be expected.

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

• The bug fix is important enough to be backported? (label: 'backport requested')
• This PR touches english.txt or translations? Check the guidelines
• This PR affects the save game format? (label 'savegame upgrade')
• This PR affects the GS/AI API? (label 'needs review: Script API')
  • ai_changelog.hpp, gs_changelog.hpp need updating.
  • The compatibility wrappers (compat_*.nut) need updating.
• This PR affects the NewGRF API? (label 'needs review: NewGRF')
  • newgrf_debug_data.h may need updating.
  • PR must be added to API tracker

[TrueBrain]

I shifted gears, and went for a "I want to use using to define a strongly typed type". I got some inspiration, and that is easily doable. Means we don't need to define a struct to create a new type, but we can just use using.

The trick here is that to avoid 2 NewStrongTypedef of the same base-type being equal, that we tag them with an unique tag. This works wonderful.

Sadly, I noticed that the compiler was sneaky converting everything back and forth between int32 for us, so you could assign a year to a date. To solve this, I made the conversion to int32 explicit, and boy, this showed a lot of places were we just depend on that. Not surprising, given we came from a world where you could. But plenty of places that are ... weird. Like % 7 on the date.

Anyway, much more interested in the overall idea of this PR, if we like defining such type this strongly. Does it actually help?

[TrueBrain]

Another update. I decided to go for Mixins, after the idea of https://github.com/anthonywilliams/strong_typedef.

What is nice about this, is that it means TileIndex can be converted too, and we deduplicate defining a new type by a lot.
The downside is that the line to define a type becomes a bit lengthy :)

[2TallTyler]

@TrueBrain A lot of this PR is way over my head with templating and casting, but you are absolutely right that we'll need this before #10700. Maybe some more experienced developers can weigh in on this? I would be eternally grateful. ❤️

[2TallTyler]

The same way you make SetDParam() take strong-typed date arguments, it might be helpful (if that's possible) to do the same with settings. That could save a lot of casting, I think.

[2TallTyler]

I don't understand template stuff well enough to review it, but the casting all looks correct to me.

If someone else reviews the template stuff, I can continue working on #10700 tomorrow! Thanks again for taking this on! 😄