Decide what to do with defaultTask in FreeRTOS application code

[rfairley]

Describe the feature
The defaultTask generation was mandated by Cube when we decoupled application code from Cube (#38). As of today, defaultTask is unused and should be removed.

Reason for request
Since Cube is now aware of the other tasks and generates a stub implementation of the others defaultTask can be removed from our application code.

Timeline
Not urgent as it is not causing problems. Can be done any time, it'd be quick to do.

[tygamvrelis]

I don't like the idea of leaving a useless thread lying around anymore than you do. I tried deleting the default task through Cube once and it didn't let me, even when there were other tasks around. However, it does allow renaming it, so we could just rename it to the name of a different thread.
Alternatively, we could re-purpose it so it runs all of our one-time setup code when the application starts up.

[rfairley]

I like the idea of re-purposing to run the one-time setup code - would nicely separate the one-time actions from the repeating actions. This could be worked in around the same time as EventHandler/EventHandlerTask is added in

[rfairley]

Also the default task may act as a boot sequence. We may define different signals for different "ready" stages in the boot process. Probably something for a while down the road though. This'll work if the default task is at lowest priority and threads block on a signal from the default task (like the situation with CommandTask).