Add: allow loading heightmaps from command-line (#11870)

If you want to load a file from tar, you have to give the file
inside the tar in order for it to work:

<tar-file>/<dir-in-tar>/<file>.png

Fix #10568: "can savegame be loaded check" failed in dedicated server

* If loading fails, it usually returns SL_REINIT which doesn't trigger check
* If savegame has NewGRFs, it complains NewGRFs are not allowed in intro game

Codechange: address CodeQL issue "Multiplication result converted to larger type" (#10306)

Most are very unlikely to ever be triggered in our codebase; two
stand out: linkgraph and money cheat. Those, potentially, could
wrap earlier than expected.

Codechange: rename str_validate to StrMakeValid(InPlace) (#9304)

This to be more explicit the function changes the value, and not
returns yes/no.

Change: reworked the debug levels for network facility (#9251)

It now follows very simple rules:
0 - Fatal, user should know about this
1 - Error, but we are recovering
2 - Warning, wrong but okay if you don't know
3 - Info, information you might care about
4 -
5 - Debug #1 - High level debug messages
6 - Debug #2 - Low level debug messages
7 - Trace information

Fix 91b8ce07: dedicated servers could no longer create screenshots (#9232)

Although most commands are not useful on a dedicated server,
screenshot commands should be dequeued.

Add: make modal windows update more smooth

Basically, modal windows had their own thread-locking for what
drawing was possible. This is a bit nonsense now we have a
game-thread. And it makes much more sense to do things like
NewGRFScan and GenerateWorld in the game-thread, and not in a
thread next to the game-thread.

This commit changes that: it removes the threads for NewGRFScan
and GenerateWorld, and just runs the code in the game-thread.
On regular intervals it allows the draw-thread to do a tick,
which gives a much smoother look and feel.

It does slow down NewGRFScan and GenerateWorld ever so slightly
as it spends more time on drawing. But the slowdown is not
measureable on my machines (with 700+ NewGRFs / 4kx4k map and
a Debug build).

Running without a game-thread means NewGRFScan and GenerateWorld
are now blocking.

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.

Add: settings to limit your fast-forward game speed

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

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.

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: Replace custom thread code with C++11 thread objects.

We assume a conforming C++11 compiler environment that has a valid <thread>-header.
Failure to run a real thread is handled gracefully.

Remove: ENABLE_NETWORK switch

This switch has been a pain for years. Often disabling broke
compilation, as no developer compiles OpenTTD without, neither do
any of our official binaries.

Additionaly, it has grown so hugely in our codebase, that it
clearly shows that the current solution was a poor one. 350+
instances of "#ifdef ENABLE_NETWORK" were in the code, of which
only ~30 in the networking code itself. The rest were all around
the code to do the right thing, from GUI to NewGRF.

A more proper solution would be to stub all the functions, and
make sure the rest of the code can simply assume network is
available. This was also partially done, and most variables were
correct if networking was disabled. Despite that, often the #ifdefs
were still used.

With the recent removal of DOS, there is also no platform anymore
which we support where networking isn't working out-of-the-box.

All in all, it is time to remove the ENABLE_NETWORK switch. No
replacement is planned, but if you feel we really need this option,
we welcome any Pull Request which implements this in a way that
doesn't crawl through the code like this diff shows we used to.

Remove: BeOS support (deprecated by Haiku)

In 10 years there is no commit to change how BeOS works, and we
have no active maintainer for it. It is unlikely it works in its
current state (but not impossible).

With the arrival of SDL2 (and removal of SDL), BeOS is no longer
support. SDL2 suggests to use Haiku instead of BeOS.

(svn r11734) -Change: Allow ToggleFullScreen to return the result of the operation' attempt. Previously, only visual clues were available.
-Fix[FS#1519]: When you can not use this resolution at full screen, now you'll know that it failed.
As for the reason it did not work, each computer/OS has its reason.

(svn r10781) -Fix: ported more pieces to WinCE, so it compiles a bit more
-Fix: WinCE doesn't support console
-Fix: Set debug lvl4 when running a debug WinCE build (as you can't give parameters any easy way)

(svn r10190) -Codechange: merged renderer and blitter to one single class API: blitter
-Codechange: introduced a hierachy of blitters to avoid a lot of code duplication
Note: this allows much easier adding other types of video-drivers, like OpenGL

(svn r10182) -Codechange: rewrite most part of the file loading/searching to be more flexible.
-Codechange: add support for personal directories on Windows.
-Fix [FS#153, FS#193, FS#502, FS#816, FS#854]: fix issues related to fixed names, fixed places of files/directories and application bundles.

(svn r10121) -Codechange: split renderer from rest of code; no longer any code directly accesses the video-buffer
-Add: added NULL blitter and renderer, which are always used for -vnull
-Add: dedicated driver doesn't blit nor render by default. Can be overruled by user. (-D -b 8bpp-optimized)
-Remove: removed CTRL+D from win32, which is incompatible with above
-Add: extended screenshot support for PNG and BMP
-Codechange: remove all hardcoded 8bpp references and replace them with more dynamic ones
-Codechange: minor stuff in blitters