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: pass "ground vehicle" to GetTileSlopeZ since for tunnel/bridges there are two states

Previously it checked the position in non-driving direction to "guess" whether
a ground vehicle was using the function, so on tunnels/bridges it could either
return the Z of the (virtual) ground compared to the Z of the path the vehicle
would take.

Codechange: make rounding code clearer

-O1 already optimizes it to the original hand optimized magic code

Fix: Don't assume engclass 2 should be elrail. (#10315)

When disabling/enabling elrail, there is an assumption that `engclass` of 2
means the engine will run on elrail. While this holds for default engines,
NewGRFs can do other things.

To resolve this we store the intended railtype so that toggling elrail will
restore to the correct type.

Codechange: Add fast path to catenary drawing in MaskWireBits

MaskWireBits always returns its input unchanged if the input
has only 0 or 1 track bits set.
Having only 0 or 1 track bits sets (i.e. non junction tiles)
is by far the most common case.
Examining the state of neighbouring tiles and the subsequent
masking logic is relatively expensive and can be omitted in this case.

(svn r27812) -Fix: Road tunnel/bridge heads have no trackbits wrt catenary drawing

Road tunnels and bridges do not have any rail, so do not treat them
as if they had when drawing a catenary. (cirdan)

(svn r20137) -Fix [FS#3945]: desync due to (temporary) wrong railtype; when loading a savegame the railtype of some (high ID) trains could be wrong.
After loading the vehicle data in the trains are updated, but after that the "electrification" checks are done which can change the "global" vehicle data. However, this update is not propagated to the vehicles until the consist is updated, e.g. turning around and going to a depot.
This makes some of the trains of a just joined client run as non-electrified trains which can cause it to take a wrong path or to not (randomly) show the electric sparks.

(svn r16909) -Fix [FS#2996]: NewGRF stations would be triggering assertions all over the place when using the more advanced station types.
-Change: make (rail) waypoints sub classes of 'base stations', make buoys waypoints and unify code between them where possible.

(svn r13681) -Revert (r13678, r13677): the fixes didn't work in all cases (assertions on savegame loads).
-Fix [FS#2102]: but now in a hopefully beter way.