scxmlc should allow generating more useful API

State machines can be a useful tool to formally specify the states a (sub-) system can be in, and what transitions within that system are valid. scxml provides an industry-standard way to specify these. Qt provides the scxmlc compiler to create a version of the machine compiled to C++, which is great in principle if to write safe code against.

Unfortunately, the API of the generated C++ is rather disappointing, and does little to facilitate actual safe code. The API is very much string-based, with methods like `connectToState(QString state, <something>)` and `submitEvent(QString eventName, QVariant data)`. While that's the only option for machines loaded from file, that doesn't lead to safe code as we cannot rely on the compiler to detect typo's in the names of these objects. For compile-time generated code, we can do better.

scxmlc does allow to generate additional properties, which results in a bunch of boolean properties representing the states. That is mildly useful, but not nearly enough. I would like to suggest:

1. Generate slots for events that can be send to the state machine, so that we can call these with directly
2. Generate signals for the events, so that once again these can be connected to directly
3. Generate signals for the entry and exit of states
4. Generate an enum (including the QMetaEnum data for it) with the states in the machine, and a method to query the current state returning these.

Ideally, the above methods and signals would have actual, type-safe arguments. I am not sure that that is feasible though from the information available, but it could at least have QVariant arguments with the correct names instead of a generic single "data" argument.

Perhaps a few custom extensions to the scxml would be needed/could be used to specify argument types and/or to specify for which states and events code should be generated.

Having this would make it much easier and safer to use a state machine specified in scxml, and get rid of a lot of error-prone boilerplate code. Using such generated code for communication with the state machine will result compile errors if the state machine is edited but the code isn't appropriately adapted to match, which would be hugely beneficial to catch any problems at compile time.