Automate generation of Interface classes from hardware API functions

[rfairley]

Describe the feature
To enable us to use mocks of classes we create in unit tests, we create virtual classes such as OsInterface, which two classes inherit from: 1) a class that actually calls the hardware API functions (OsInterfaceImpl) and 2) a mock class MockOsInterface which is used in unit tests see (Common/tests/OsInterface_test.cpp).

These classes have function signatures which match function signatures of the underlying hardware API (return value and parameters at least) (e.g. osSemaphoreWait() in cmsis_os.h and OsInterface::OS_osSemaphoreWait() in our virtual class, and use the same types defined in the underlying hardware API. E.g., cmsis_os.h defines osSemaphoreId which the virtual function we defined OS_osSemaphoreWait() returns. Because of the matching signatures and types, virtual interface classes like OsInterface are closely tied to the hardware API, which is cmsis_os.h in OsInterface's case.

The process of writing out the function declarations for the virtual classes is quite mechanical, and can take some time if there are a lot of function calls we need to virtualize. We should try and automate generation of the interface class definition for a given hardware API. This would look like the following for a single function call:

stm32f4xx_hal_uart.h

...
HAL_StatusTypeDef HAL_UART_Transmit(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size, uint32_t Timeout);
...

↓

UartInterface.h

...
namespace hal
{
class UartInterface
{
public:
  virtual HAL_StatusTypeDef transmit(
        UART_HandleTypeDef* huart,
        uint8_t* pData,
        uint16_t Size,
        uint32_t timeout
    ) const = 0;
} // class UartInterface
} // namespace hal
...

This might take the form of a script (e.g. in Python) that parses function declarations in the original driver file
stm32f4xx_hal_uart.h, and writes the new declaration in the hal::UartInterface class in UartInterface.h.

Reason for request

Save time writing out function parameters and return values for virtual classes that we only ever use as a bridge between hardware code and mock code in unit tests.

Timeline
Not urgent - no timeline.

Additional information

It's expected that we might want to make our own manual adjustments, e.g. changing the generated transmit function to transmitPoll for better clarity (like we have done already). Automating the bulk of the writing out parameters and return values would still save a lot of time.

Possibly extend this to generate the Impl class like OsInterfaceImpl too.