A10: do ARC-210 preset programming in default MFD location when possible

[fizzle77]

This is based on the a10-misc-system-additions branch and shouldn't be merged before #11.

• Re-ordered the ARC-210 programming slightly, so pilots can monitor guard and the initially set freq while preset programming happens.
• If the COMM page is in its default location on the left MFD, do the preset programming for the ARC-210 there. This will be true 99% of the time.
• If COMM is not in its default location on the left MFD, replace MSG on the right MFD as before, set the presets, and put MSG back when done.

If we could marshal string return values back from LUA functions to .NET, such that I could run a function like GetLMFDButton12Text, it would be nicer to just always do this in the default location and put back whatever was originally there. But I'm still pretty mystified by that code and not even sure if this is possible. And I don't want to run 10 nested IfBlocks to go through all the possibilities. Suggestions welcome if I've missed something here.

Closes fizzle77#3.

[ilominar]

The "button mashing" code really isn't built for exchanging data between DCS and JAFDTC. Underlying assumption is you build a complete sequence that is sent to DCS and executed. There's no "Send Command Q", "Get response R", "Send command A or B based on R" path at this time (getting there would require a lot more complex networking code than is currently implemented, and not clear if it would fit in with the context of the frame-based ticks that drive the DCS side).

Best bet would be to do something on the DCS side. Maybe like this: build DCS-side custom Lua functions for the A10 (called through AddRunFunction) "Push MFD Format" that saves current format to a global and "Pop MFD Format" that restores state per global. Then bracket the section in Build() with the push/pop.

AddIfBlock("mfd not in right format", AddRunFunction("push mfd format"); AddAction(device, "set mfd to right format"); ); AddAction(device, "button"); AddAction(device, "button"); AddRunFunction("pop mfd format");

In this case, pop would do nothing if there was nothing pushed. You could potentially absorb some of the if block and so on into the Lua, but there's a slippery slope there in trying to keep the setup on JAFDTC and not have to read both C# and Lua to figure out what button mashing is going on.

The global state is a bit gross, but not sure there's a cleaner way to do it.