Fix: [MacOS] screen looks blue-ish when using newer SDKs (#11207)

The define kCGBitmapByteOrder32Host changed (around SDK 12?)
into an enum, which means an old #ifndef was triggering,
overwriting the value to 0. Sadly, 0 means Order16Big, causing
RGBA to become GRAB, which results in strange colours.

As we no longer support PPC, drop that piece of code completely.

Codechange: automatic adding of _t to (u)int types, and WChar to char32_t

for i in `find src -type f|grep -v 3rdparty/fmt|grep -v 3rdparty/catch2|grep -v 3rdparty/opengl|grep -v stdafx.h`; do sed 's/uint16& /uint16 \&/g;s/int8\([ >*),;[]\)/int8_t\1/g;s/int16\([ >*),;[]\)/int16_t\1/g;s/int32\([ >*),;[]\)/int32_t\1/g;s/int64\([ >*),;[]\)/int64_t\1/g;s/ uint32(/ uint32_t(/g;s/_uint8_t/_uint8/;s/Uint8_t/Uint8/;s/ft_int64_t/ft_int64/g;s/uint64$/uint64_t/;s/WChar/char32_t/g;s/char32_t char32_t/char32_t WChar/' -i $i; done

Codechange: use _cur_palette the same in all the drivers

It was a bit of a mixed bag. With this change, gfx.cpp is in
control who accesses _cur_palette from the video-drivers.

Codechange: [OSX] Use more exact enum names where introduced with the 10.12 SDK.

The enum values still have the exact same numerical values, but the 10.12
SDK introduced more explicit names (e.g. like NSEventTypeApplicationDefined
instead of NSApplicationDefined) for several enum constants.
Use them when available.

Add: [Video] move GameLoop into its own thread

This allows drawing to happen while the GameLoop is doing an
iteration too.

Sadly, not much drawing currently can be done while the GameLoop
is running, as for example PollEvent() or UpdateWindows() can
influence the game-state. As such, they first need to acquire a
lock on the game-state before they can be called.

Currently, the main advantage is the time spend in Paint(), which
for non-OpenGL drivers can be a few milliseconds. For OpenGL this
is more like 0.05 milliseconds; in these instances this change
doesn't add any benefits for now.

This is an alternative to the former "draw-thread", which moved
the drawing in a thread for some OSes. It has similar performance
gain as this does, although this implementation allows for more
finer control over what suffers when the GameLoop takes too
long: drawing or the next GameLoop. For now they both suffer
equally.

Remove: [Video] no longer draw in a thread

Drawing in a thread is a bit odd, and often leads to surprising
issues. For example, OpenGL would only allow it if you move the
full context to the thread. Which is not always easily done on
all OSes.
In general, the advise is to handle system events and drawing
from the main thread, and do everything else in other threads.
So, let's be more like other games.

Additionally, putting the drawing routine in a thread was only
done for a few targets.

Upcoming commit will move the GameLoop in a thread, which will
work for all targets.

Fix #8784: using alt+enter didn't update the fullscreen toggle visibly (#8820)

Basically, the window was not invalidated, so it was never redrawn.
This made it look like it wasn't working, but it really was.

Add: settings to limit your fast-forward game speed

By default this setting is set to 2500% normal game speed.

Codechange: [OSX] GameLoop is really more like MainLoop

MainLoop() is used to bootstrap OSX, where later a callback is
done to GameLoop() to execute OpenTTD. All other video drivers
don't need that, so what is in GameLoop is in MainLoop for all
other drivers. This is rather confusing. So, instead, name
GameLoop MainLoopReal to be more in sync with the other drivers.

Codechange: [Video] make the prototype of PollEvent() the same for all drivers

Additionally, call it from the draw-tick.

Codechange: [OSX] Only keep a total dirty rect for drawing.

When drawing an 8bpp screen buffer, palette resolving was done for each
dirty rectangle. In areas with high activity, this would mean a pixel might
have been resolved multiple times. Also, if too many individual updates
were queued, the whole screen would be refreshed, even if unnecessary.

All other drivers only keep one overall dirty rect, so do it here as well.

Codechange: deduplicate tick-handlers of all video drivers

They were all identical, so better put this in a single place
hoping it is less likely to break.

Codechange: be consistent in naming the paint function Paint()

Also move this function to be a class member. This to allow
further deduplicating of code in a later commit.

Fix: during switching of game-mode, drawing could show closed windows that shouldn't be closed yet

The higher your refresh-rate, the more likely this is. Mostly you
notice this when creating a new game or when abandoning a game.

This is a bit of a hack to keep the old behaviour, as before this
patch the game was already freezing your mouse while it was changing
game-mode, and it does this too after this patch. Just now it
freezes too a few frames earlier, to prevent not drawing windows
people still expect to see.

Feature: configurable refresh-rate and change default to 60fps

Most modern games run on 60 fps, and for good reason. This gives
a much smoother experiences.

As some people have monitors that can do 144Hz or even 240Hz, allow
people to configure the refresh rate. Of course, the higher you
set the value, the more time the game spends on drawing pixels
instead of simulating the game, which has an effect on simulation
speed.

The simulation will still always run at 33.33 fps, and is not
influences by this setting.

Change: sleep till the next tick in the main loop

Sleep for 1ms (which is always (a lot) more than 1ms) is just
randomly guessing and hoping you hit your deadline, give or take.

But given we can calculate when our next frame is happening, we
can just sleep for that exact amount. As these values are often
a bit larger, it is also more likely the OS can schedule us back
in close to our requested target. This means it is more likely we
hit our deadlines, which makes the FPS a lot more stable.

Change: allow video-drivers to miss deadlines slightly

Before, every next frame was calculated from the current time.
If for some reason the current frame was drifting a bit, the
next would too, and the next more, etc etc. This meant we rarely
hit the targets we would like, like 33.33fps.

Instead, allow video-drivers to drift slightly, and schedule the
next frame based on the time the last should have happened. Only
if the drift gets too much, that deadlines are missed for longer
period of times, schedule the next frame based on the current
time.

This makes the FPS a lot smoother, as sleeps aren't as exact as
you might think.

Add: draw the screen at a steady pace, also during fast-forward

During fast-forward, the game was drawing as fast as it could. This
means that the fast-forward was limited also by how fast we could
draw, something that people in general don't expect.

To give an extreme case, if you are fully zoomed out on a busy
map, fast-forward would be mostly limited because of the time it
takes to draw the screen.

By decoupling the draw-tick and game-tick, we can keep the pace
of the draw-tick the same while speeding up the game-tick. To use
the extreme case as example again, if you are fully zoomed out
now, the screen only redraws 33.33 times per second, fast-forwarding
or not. This means fast-forward is much more likely to go at the
same speed, no matter what you are looking at.

Codechange: track _realtime_tick more accurate

_realtime_tick was reset every time the diff was calculated. This
means if it would trigger, say, every N.9 milliseconds, it would
after two iterations already drift a millisecond. This adds up
pretty quick.

Codechange: switch all video drivers to std::chrono for keeping time

On all OSes we tested the std::chrono::steady_clock is of a high
enough resolution to do millisecond measurements, which is all we
need.

By accident, this fixes a Win32 driver bug, where we would never
hit our targets, as the resolution of the clock was too low to
do accurate millisecond measurements with (it was ~16ms resolution
instead).

Codechange: [OSX] Split drawing into its own subview.

This allows the drawing backend code to be independent
of any event or command handling.

Change: [OSX] Replace screen resolution list with suggested window sizes.

We never change the real screen resolution on OSX. As such, offering a list
of resolutions is pointless. Instead of that, offer the user a list of
commonly used window sizes up to the current screen size.

Revert 4ce53cb8: [OSX] Delayed fullscreen switch is not needed anymore.

The fix for #8067 solves the real issue, making this workaround unneeded.

Fix: [OSX] Quitting in fullscreen mode would loose the original window size.

This replicates the behaviour on e.g. Windows, which saves the original window size.

Codechange: [OSX] Re-arrange the OSX video driver code by combining all drawing code and moving the window/event handling to a different file.

This is just a code move/rename, not a functionality change.

Remove: [OSX] Old fullscreen subdriver for pre 10.7 systems.

Since the move to C++11, building for pre 10.7 is not possible with the native
Apple tools. Also, due to bitrot, the file doesn't even compile anymore. While
this could be fixed, it shows that this subdriver is basically never used anymore.

Remove: [OSX] QuickDraw video subdriver used for OSX versions up to 10.4.

Since the C++11 move, getting OpenTTD to compile and run for anything
below 10.7 basically requires building a custom compiler and libc++.
Also, the QuickDraw subdriver crashes on more modern OSX version. While this
is fixable, keeping the driver around is probably pointless.

Change: [OSX] Recreate backing store if the colour profile of the screen (or the screen) the game window is one changes.

This will result in changing colours if moving OpenTTD from one screen to another, but should avoid performance problems if the window is moved.