Add Alternate Syntax for Confusing Tokens

[SteelFill]

Some tokens have syntax that doesn't conform to user expectations, resulting in some users, even payware developers, to either use syntax that doesn't work or to just avoid some features as the inconsistent syntax is too confusing to use. This PR adds alternate syntax to allow the confused tokens to be implemented in ways users expect and understand.

Specifically:

• Adding ORTSAirBrakeMainResVolume as an alternate token for AirBrakesMainResVolume. Some community members, and even payware developer TrainSimulations, were misled into thinking this token existed when it did not, resulting in locomotives with smaller (default-sized) main reservoirs than intended. As this 'ORTS...' syntax has been used so much, it makes more sense to add it officially than to attempt to change the minds of those who have used it for years.
• Allowing tokens which normally need to be in an orts ( ) block to also be parsed if placed outside of an orts ( ) block. A very small number of tokens needed to be in an engine(orts( section, which is ultimately redundant as the token names already have 'orts' in them, and is also confusing because it is inconsistent with the multitude of tokens which do not require an orts ( ) block. Users have shown confusion with the whole orts ( ) block thing, and some have gotten the impression that the orts ( ) block isn't necessary (even though it is), so allowing this alternate should vibe better with people.
• Similar story for tokens that would require an ortsadhesion ( ) block. While this is more sensible than the orts ( ) block, there's 2 ORTSAdhesion( ORTS... ( tokens, which is still redundant, adding unneeded complexity and room for user error.

Parsing of the original syntax still remains to retain support for users who were able to decipher the correct formatting. Similarly, I'm not intending on changing the documentation for these tokens as the changes here are only intended to be a fallback to account for user error and their use does not need to be encouraged.

Discussion on this issue came up here on ElvasTower, in response to the tweaks to sander behavior included in PR #840, and the subsequent confusion that ORTSSanderSpeedEffectUpTo wouldn't work unless inside an engine(orts( section.

[cesarBLG]

Looks OK to me