Faster tuner on v2 hardware

[sastraxi]

The tuner's DSP loop and LCD refresh were both doing unnecessary work on every frame. This PR adds back the Tuner menu item for v2 and ports optimizations from lcd/more-speed-tuner:

• YIN detector: pre-allocates its scratch arrays once at startup instead of every frame, and works in float32 throughout. ~15% reduction in CPU usage
• Strobe widget: batches all the partial-column LCD refresh calls for a given tick into a single SPI transfer instead of firing up to 12 separate ones. Basically, do a big blit instead of many smaller blits, because the pixel bookkeeping that reduces SPI transfers kills us in terms of CPU time. Fewer SPI round-trips = less CPU time spent waiting on the display bus
• Reduces target frame rate from 100fps to 50fps to fit in new SPI budget (coalesced transfers mean more pixels transferred per frame)

[rreichenbach]

This is much better. The tuner is usable. It does still spike the CPU, especially on start. Enough to cause overruns - 10 to 20 maybe, but not hundreds like before. My main concern is crashes when used with already demanding pedalboards, but perhaps having it somewhat hidden under the system menu makes it available for those who really want it.

[sastraxi]

This is much better. The tuner is usable. It does still spike the CPU, especially on start. Enough to cause overruns - 10 to 20 maybe, but not hundreds like before. My main concern is crashes when used with already demanding pedalboards, but perhaps having it somewhat hidden under the system menu makes it available for those who really want it.

If you change def lcd_poll_divisor in modhandler to return a higher number when the tuner panel is active, you can lower CPU further. Anything up to 8 is still usable IMO, but it does hurt the immediacy somewhat of understanding if you're flat or sharp.