Bugfix/bldc controls

[finger563]

Description

• Fixed enable/disable code for the bldc driver so that it starts/stops the timer in the enable/disable function and does not use the force since that was preventing the driver from working after the disable was called once.
• Removed extra / unused logging
• Removed mutexes around gpio
• Added check on enable pin number before setting enable pin in enable()
• Enable the motor explicitly in the constructor to initialize foc, then disable it before leaving constructor
• Added function to get enabled state of motor
• added additional named method is_running as alternative for is_started
• Ensure when breaking loop for bad callback function the started_ member is set to false.
• Added destructor to stop haptics when destroyed
• Updated start/stop functions to enable/disable motor as well
• Added API to see if the haptics are running/active or not
• Re-ran clang-format on all files

Motivation and Context

Right now the bldc components did not support being reenabled after being disabled - everything would appear to work, but the actual output would continue as if the driver were disabled. This resulted from the fact that we were calling the force output functions on the generators in the disable call. Removing those calls from the enable and disable functions and replacing them with timer start and timer stop calls has the same intended effect (ensuring power/no power to the motor) in a way that allows for as much cycling of enabled / disabled state as you like. Additionally, ensuring that the container / higher level classes maintained enabled/disabled state of the underlying classes simplifies the interfaces / API. Finally, we want to ensure that the motor control classes are in a safe (no power) state after initialization / construction is finished.

How has this been tested?

Building and running the bldc haptics test.

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
• Hardware (schematic, board, system design) change
• 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.
• I have updated the .github/workflows/build.yml file to add my new test to the automated cloud build github action.
• All new and existing tests passed.
• My code follows the code style of this project.