Improved Software Generator and updated HFSM runtime API

[finger563]

Description

• Allow software generator to genreate state machine code into a user-specified namespace (default is the original state_machine)
• Updated generated HFSM code to remove use of DEBUG_OUTPUT preprocessor guard around std::cout in favor of allowing users to specify a log function that is used (if not null) to log data. This enables dynamically changing the logging at runtime as well as running multiple HFSMs with different logging (as well as to log to file if desired)
• Update HFSM Root / EventFactory interface to have a condition variable for the event queue which allows callers to block until they are notified that there is a new event in the queue.
• Update HFSM Root interface to have a sleep function which sleeps until either the current state timer period expires or a new event appears in the queue
• Updated HFSM test bench generated code to run the HFSM in a separate thread and use the new interfaces for showing a more realistic / better way of executing and communicating with the HFSM.

Motivation and Context

• Sometimes (for code style / compatibility reasons) people want to generate the state machine code into a custom namespace, this PR allows for that
• When running an HFSM, it would be nicer to build in common usage patterns into the API, such as sleeping until either the current state timer period expires, and waiting until a new event is added to the queue
• The test bench code should show a slightly more useful / common pattern for state machine execution, so this PR changes the test bench so that the HFSM runs in its own thread, and the CLI / event generation happens in another thread

How has this been tested?

Building and running each of the example HFSMs.

Screenshots (if appropriate, e.g. schematic, board, console logs, lab pictures):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation Update
• Software change

Checklist:

• My change requires a change to the documentation.
• I have added / updated the documentation related to this change via either README or WIKI

Software

• I have added tests to cover my changes.
• All new and existing tests passed.
• My code follows the code style of this project.