New: Add power supply types, voltages etc. to CSV / RW routes

[leezer3]

This PR adds power supply voltages and types etc. to the CSV route parser.

Currently, these are handled by a set of non-standard beacons and the associated runtime plugin.

New Routefile Commands:

n.b. These commands apply from the start of a block.
Track.PowerSupply RailIndex, PowerSupplyType, VoltageType, Voltage, Amperage, ContactHeight
Starts a new power supply.

• RailIndex- The rail index to start the power supply on.
• PowerSuplyType- The type of power supply, can be one of the following 1 or OHLE - Overhead line. 2 or ThirdRail - Third rail 3 or FourthRail - Fourth rail.
• Voltage- The voltage supplied.
• Amperage- The maxium current draw.
• Contact height- The contact height above / below railhead for the conductor.

Default values are as follows:
OHLE- 25,000v, AC, 1,000A, 5.3m contact height
Third rail- 750v, DC, 3,000A, 0m contact height
Fourth rail- 750v, DC, 3,000A, 0m contact height

Track.PowerSupplyEnd RailIndex, PowerSupplyType
Ends the given power supply.

• RailIndex- The rail index to end the power supply on.
• PowerSuplyType- The type of power supply to end, can be one of the following 1 or OHLE - Overhead line. 2 or ThirdRail - Third rail 3 or FourthRail - Fourth rail.

TODO:

BEFORE MERGING

• Add current collector track followers to trains.
• Add control over where the current collector is placed.
• Add variables to animated objects. - TEST IMPLEMENTATION
• Allow pantographs to be set via XML.
• Pass out in the runtime data.
• (??) Add routefile command to set neutral section- Could equally do it by setting zero volts in the Track.PowerSupply command?

THOUGHTS AND IDEAS

• ?? Allow a specific train to only work with specific power supply types ?? - Easy enough to implement (just hold the handles at zero if not present) but likely to be detrimental to user experience?
• Other power supply types? I suppose we could add stuff like racks to this sort of bit, but is it the right place?
• Related- Do water troughs / diesel fuelling points fit into this framework, or do they require a separate thingy again?

[leezer3]

Secondary thought-
The pantograph adding code is nastily complex.

Would we be better with just adding a pantograph to all cars?
This would allow us to call the wireheight function for any car, not just one with a pantograph attached (What behaviour should this have anyways???)
Then make it an XML property as to which pantographs pickup power- Using this in any meaningful way is likely to be a long way down the line?

[leezer3]

More thoughts:

Do the pantograph and beacon follower need to be moved into a nice class thingy?
At the minute, each adds an unnecessary property to the base car as to the location. This should be probably hidden.

Further:

The BeaconFollower is always positioned in the center of the car. Moving this will break legacy compatability, but in a prototypical unit the reciever for track based transducers (AWS, TPWS etc.) would be mounted on the leading bogie at each end of a unit.

[leezer3]

Simplified by adding the pantograph to all cars (train.dat) as per the thoughts above.

For adding to train.xml, something like this will be wanted I think:

<Pantograph>
<Fitted>true</Fitted>
<Location>0.5</Location>
</Pantograph>

Obviously, just set the pantograph to null otherwise.
Marginal change:
Pantographs are fitted to all cars, but have a CollectsPower property. This allows us to query the wire height for any car index, but return zero volts if no current is to be collected.

Probably too complicated to allow a pantograph to only recieve one type of current, this logic should be handled in the train itself.

[leezer3]

Last commit isn't strictly related to this, but will be doing work in there shortly to add the voltages to the API data provided & this was another oversized lump file which needed splitting into the component classes.

[leezer3]

Basic implementation is complete for this.
Next question is how to handle this with the runtime data. At the minute, this only supplies a per-train VehicleStatus not a per-car set of bits.
Probably just return the train's power supply collection? (Assume pantographs are set where required by Train.xml, this would probably work OK)

Doing this has the minor issue of adding another overload to the vehiclestatus constructor, but this is inevitable with the current C# way of doing things.

[leezer3]

Manually brought this branch up-to date with the current master.

Needs testing, not sure what if anything is now broken.
Might need a little optimisation / caching too.