HardwareTimer: Allow delaying initialization to setup method

[matthijskooijman]

Previously, the only way to initialize a HardwareTimer instance was to
pass an instance to the constructor. When using a global (more
specifically, with static storage duration) HardwareTimer instance, the
initialization would happen early in startup, before main() and setup()
had a chance to run. This would mean that on any errors (e.g. no timer
found for a specific pin when using e.g. pinmap_peripheral), the board
would just lock up in early startup, unable to show a meaningful error
at all.

To prevent this, you would have to allocate the HardwareTimer object
dynamically on the heap, but that is not always a good idea from a
memory management perspective.

This commit adds an argumentless constructor that does not initialize
the timer yet, and a setup() method that accepts the timer instance and
does the actual initialization. This allows delaying the actual
initialization until in or after the sketch setup() function, and also
makes it easier to change the timer to use dynamically, based on e.g.
user input or EEPROM contents or similar.

Note that de-initializing a timer and switching to using a different one
is not currently supported, trying to call setup() twice results in an
error.

[matthijskooijman]

Note that I have not tested this particular commit in the main branch, but it is forward-ported verbatim from a slightly customized STM32 core we are using (where this commit works as expected). Looking at the diff between both versions for HardwareTimer, I would not expect any issues.

[matthijskooijman]

I've pushed some astyle fixes.

[fpistm]

Hi @matthijskooijman
Thank you for this PR, @ABOSTM will review it soon 😉

[ABOSTM]

@matthijskooijman Thanks for this PR. It makes sense.
LGTM.