add MAX11300 ADC range & various small fixups

[TheSlowGrowth]

This PR adds the 0 .. 2.5V ADC voltage range to the MAX11300 driver. This range is useful when connecting pots / sliders as it results in a much lower current through those components, compared to the full 10Vpp of the other ranges.

As this range is not available for the DAC outputs, the existing enum VoltageRange was split into two enums, enum DacVoltageRange and enum AdcVoltageRange.

Some other small fixups included in this PR:

• made the MAX11300 getter functions const
• removed unused argument from FIFO, resolving a compiler warning
• changed the optimization settings used for CMake Debug builds. The -Og setting that us currently used is adding tons of optimization that makes debugging very hard. It was changed to -O0

[TheSlowGrowth]

@recursinging please take a look at the changes

[recursinging]

@TheSlowGrowth, Everything looks good to me. Splitting up the VoltageRange enum is the best way to safely make the 0..2V5 range available. The rest of the changes are sensible.

Thanks for the contribution!

[TheSlowGrowth]

@recursinging: I adjusted the tests. They expected the lowest bit of the range bits in FUNCPRM 8:10 to be set for digital read/write mode and the high impedance mode (that would equal to the default 0..10V range). All three of these modes don't actually use these bits, so I think it's safe to adjust the test expectations.

Am I correct?

[recursinging]

@TheSlowGrowth Yes, that is correct. There was an error in the logic of application of the range bits that has been corrected by your changes. The test expectations should be updated to reflect the corrected logic.

[stephenhensley]

@TheSlowGrowth @recursinging everything looks good to me!

I don't have any hardware with this device. So I'll defer to your testing, etc. I can merge whenever.

Assuming the changes to ringbuffer.h were just to get rid of some CMake build warnings for unused function arguments, or something?

[TheSlowGrowth]

@stephenhensley I tested it here on my tape looper board and it works just fine. I'm working on some more changes to support multiple MAX11300 from one driver, using one SPI bus with multiple software controlled NSS pins. That'll come soon, hopefully.

[...] the changes to ringbuffer.h [...]

Yes. I have a new macbook where the Xcode toolchain installs clang 13.0.0 by default. This results in warnings in the unit test build, which are elevated to errors. Could be worth to add a matrix build setting to the CI so that we catch these kind of errors earlier.

[TheSlowGrowth]

See #460

[stephenhensley]

@TheSlowGrowth sounds good to me! Looks like you're working on some fun stuff!

And yeah, that makes sense. I'd seen similar happen when using DaisySP with non-standard builds. Just wanted to clarify.