Fix for neopixels on <100MHz STM32 boards

[hierophect]

Unlike the Atmel and NRF ports, the STM32F series has many different max CPU speeds across the starter, foundation and advanced lines. At lower CPU speeds, the previous neopixel code encounters an issue where the cycle time required to change a GPIO pin begins to approach the maximum allowable logic high period for a neopixel 0 bit. This results in the neopixel outputting a strong white as every bit is evaluated as 1 rather than 0.

I had hoped to replace the system with a weighted one, where the processor cycles needed to change the GPIO pins would be subtracted from the timing, making timing consistent across all frequencies. Unfortunately, I haven't managed to get a fully dynamic system granular enough to be workable. In lieu of writing the whole thing in assembly, I've just shuffled the timing enough to hit acceptable timing across most frequencies. It should work on any ST chip higher than 84MHz, and is protected against optimization differences.

As a side note, if anyone's used the ARDUINO_ARCH_ARDUINO_CORE_STM32 code here, I'd be interested to know if it works, since I don't see how the theoretical timings it uses could cooperate with the 0.22us cycle time required for the functions it uses without added trickery. It might provide some insight on this issue.

Resolves #2346. @dhalbert, maybe you could also give it a shot on your dud feather and see if it helps at all?

Bin for Feather below, but it won't do anything other than not break - will be more relevant once #2315 passes review. Also applies to the F411 Discovery, if anyone else has one.
firmware.bin.zip

[tannewt]

Perfect! Thank you!