Improve automation parameters, add functionality for more automation

[jhakala]

Taken from #330. Notes from that issue:

If we have AutoConfigure, why not AutoStart or TakeRun?

This could be done but I'd like to brainstorm how best to expand the automation functionality. Right now we have a special BoolT FM parameter for EXIT and AUTOCONFIGURE, so instead of making more and more special parameters, we could devise an all-purpose automation parameter. I am thinking the best solution is to replace the current automation parameters with a MapT that specifies a map of {state: command} to carry out automatically, i.e. an automatic start could be encoded as:

{  "Initial": "Initialize",
   "Halted": "Configure", 
   "Configured": "Start"
}

My first thoughts are that that format would make it a lot easier to define new automated actions in the future; e.g. one would not have to give a special name to a sequence of actions and implement it specifically; instead one would either:
a) put the exact JSON for a series of steps into the GUI code, and handle it there, or
b) abstract it out of the GUI a bit; instead, have the GUI send e.g. a StringT AUTOSTART over to the server side, and then the FM server-side code can populate the correct series of actions into the JSON parameter. That way the GUI code could be less in charge of defining the sequences for a particular routine. [This solution would probably mean creating two new parameters, the MapT that specifices the actions (populated on the server side), plus a StringT that the GUI populates for the GUI to send over to the server-side--it would read the StringT and then populate the MapT of actions.]