Revert #11993: new number format system does not and cannot work for CJK languages

There are too many intricacies that I am unaware of that are popping up after
asking whether things are right or not.
I do not want to keep playing whack-a-mole, so just revert the whole thing.

This reverts:
15be383b934dbf7c876b6d6ffaec7a406c82a39f
360fe8b0b639be9d39bc03a9d5d34123204c14fa
1aa9a5c0abaf9c5d6c49a3a76e2b1d7134c0bd10
59f56941e50bd4ebad31f9e771a4441f647692e5
7e2eefb91ff5999667752eea6e13bd8a0d293f48
b741b2ba6f790891961cb66a9320e75ca168cee4
609d0071d5e6b93aa61688714e9b92cf102e4683
9f8fd80112c188675179c9568a9be84da3df1713
a253205b932cc50fc9f25be390a6aaa370f89a45
819c6c756edd68599571eae126f305d6e3d247fc

Remove: setting "no_http_content_downloads" (#12058)

As we now use HTTPS, it is very likely this will work on most systems.
For systems that do have HTTPS blocked, it will fail instantly,
and it will fallback to TCP anyway. That makes this setting no longer
very useful.

Codechange: Store Colours in Colours type. (#11625)

This reduces casts, some magic numbers, and introduces a bit of type-safety.

Fix: Ensure saveload type match variable type.

This either changes the saveload definition or changes the variable depending on which makes more sense.

Codechange: Don't keep autosave_interval in std::chrono::minutes.

This variable is saved as a setting which requires the variable type to be known, but std::chrono::minutes may vary depending on system type.

Instead, keep as uint32_t and convert to std::chrono::minutes only when setting the timer.

Feature: Add config option to set default company secondary colour for new games

This does duplicate translation strings for the colours

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

Change: Add separate setting for server sent commands per frame limit (#11023)

Set a higher default value for this setting.
Use the higher of this and existing commands per frame limit
setting for server-originating commands, e.g. GS.

This is to support the GSAsyncMode class.
This also avoids undue throttling when more than one
script is in operation (e.g. AIs).

Feature: opt-in survey when exiting a game

On first start-up, the game will ask if you want to participate
in our automated survey. You have to opt-in, and can easily opt-out
(via the Options) at any time.

When opt-in, whenever you exit a game, a JSON blob will be send
to the survey server hosted by OpenTTD. This JSON blob contains
information that gives a global picture of the game just played:
- What settings were used
- How many humans vs AIs
- How long the game has been played
- Basic information about the OS / CPU

All this information is kept very generic, so there is no
chance we send private information to our survey server.
Nothing in the JSON blob could identify you as a person; it
mostly tells about the game played. At any time you can see
what the JSON blob includes, by pressing the "Preview Survey
Results" button in-game.

Change: replace per-AI "start_date" with a global "competitors_interval" (#10653)

The per-AI "start_date" is a lot of custom code, and was rarely
used in the way it was meant.

While at it, also ported this part over to the new timer system.

Feature: Separate rail/road and sea/air velocity units, and add knots. (#10594)

This is achieved by packing vehicle type along with the velocity so that
the string system can decode and pick the appropriate unit.

Change: remove the ability to control "max spectators" (#9466)

Soon we will make "join game" join the game as spectator first,
so limiting the amount of spectators makes no sense anymore in
that context. Not sure it ever did make sense.

Feature: allow the use of TURN to connect client and server together

TURN is a last resort, used only if all other methods failed.
TURN is a relay approach to connect client and server together, where
openttd.org (by default) is the middleman.

It is very unlikely either the client or server cannot connect to
the STUN server, as they are both already connected to the Game
Coordinator. But in the odd case it does fail, estabilishing the
connection fails without any further possibility to recover.

Add: allow setting your server visibility to "invite-only" (#9434)

In this mode you do register to the Game Coordinator, but your
server will not show up in the public server listing. You can give
your friends the invite code of the server with which they can
join.

Feature: join servers based on their invite code

This removes the need to know a server IP to join it. Invite codes
are small (~7 characters) indentifiers for servers, which can be
exchanged with other players to join the servers.

Remove: old server listing via Master Server

This removes all UDP from the game except for a local broadcast
to find LAN games.

So long Master Server, and tnx for all the fish!

Codechange: use NetworkAddress instead of two host/port variables where possible

This also means we no longer need last_host/last_port, but can
just use a single last_joined setting.

Remove: "language" field from server/client

The original idea was that people could find a server they could
talk in their native language on. This isn't really used in that
way. There are several reasons for removing this:

- the client also sends his "language" to the server, but nothing
is doing anything with this.
- flags are a bad way to represent languages, and over the years
we had several (rightfully) complaints about this.
- most servers have their language set to "All", and prefix the
servername with the language it is about. This is a much more
efficient way to do the same.

All in all, this feature should go back to the drawing board.
Maybe it could work in another form, but this form is not it.

Feature: allow setting a custom terrain type to define highest peak

At least, TGP will try to reach it. It heavily depends on the map
if it is reachable at all. But for sure it will do its atmost to
get there!

Add: allow setting the highest mountain for heightmaps

It will add some slack to the map height limit if that was set
to auto.

Change: rename setting "max_heightlevel" to "map_height_limit"

This better reflects what it is, and hopefully removes a bit of
the confusion people are having what this setting actually does.

Additionally, update the text on the setting to better inform
users what it is doing exactly, so they can make an educated
decision on how to change it.

Next commit will introduce an "auto" value, which should be the
new default. The rename has as added benefit that everyone will
start out on the "auto" value.

Feature: setting to indicate desert coverage for tropic climate

This is an indication value; the game tries to get as close as it
can, but due to the complex tropic rules, that is unlikely to be
exact.

In the end, it picks a height-level to base the desert/tropic
line on. This is strictly seen not needed, as we can convert any
tile to either. But it is the simplest way to get started with
this without redoing all related functions.

Feature: setting to indicate snow coverage for arctic climate (replaces snow line height)

Setting the snow coverage (in % of the map) makes a lot more sense
to the human, while still allowing the niche player to set (by
finding the correct %) a snow line height they like. This makes for
easier defaults, as it decoupled terrain height from amount of snow.

Maps can never be 100% snow, as we do not have sprites for coastal
tiles.

Internally, this calculates the best snow line height to approach
this coverage as close as possible.

Codechange: validate that "max" value of settings fit in their storage

This is an easy mistake to make, so protect us against making such
mistakes, by validating it doesn't happen.

Add: settings to limit your fast-forward game speed

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

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: Remove disable_unsuitable_building setting

This setting is no longer useful, as you can now always build roads,
canals, etc.

Feature: Configurable game ending year

Functionally reverts 683b65ee1

Change: Limit memory allocations for each Squirrel instance

This can avoid out-of-memory situations due to single scripts using up the entire address space.
Instead, scripts that go above the maximum are killed.
The maximum is default 1 GB per script, but can be configured by a setting.

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.

Feature: Industries with neutral stations (e.g. Oil Rig) only supply/accept cargo to/from their neutral station. (#7234)

This change is a controlled by a game setting, located under Environment ->
Industries which allows toggling the behaviour. It defaults to enabled.

"Company stations can serve industries with attached neutral stations"

When enabled, industries with attached neutral station (such as Oil Rigs) may
also be served by company-owned stations built nearby. This is the traditional
behaviour.

When disabled, these industries may only be served by their neutral station.
Any nearby company-owned stations won't be able to serve them, nor will the
neutral station serve anything else other than the industry.

Add: Option for population-linear town cargo generation

Introduce a new default algorithm for town cargo generation (passengers and mail), and a game setting to choose between the new and original algorithm.

The original town cargo generation algorithm has the property of the generated amount relating to the square of each building's population, meaning large towns easily produce more cargo than can realistically be transported. The problem is excessive cargo is amplified if playing with cargodist.

The new algorithm introduced instead has a linear relation to the population. The result is that smaller towns will produce slightly more cargo, while the largest towns will produce about a fourth of what they would with the original algorithm.

Existing savegames will use the original algorithm, while new games will default to the new algorithm.

Add #4115: default company colour setting (#6998)

Works only in single player.

(svn r25508) -Change: split unit localisation choice into a choice per type of unit, and move it to the advanced settings
-Feature [FS#5482]: have tractive effort in imperial (lbf) and metric (kgf) units
-Feature: have weights and volumes in imperial units (short tons, gallons)