queue throttling + slave latency and minor refactor

[liquidraver]

We had an edge case that turned out to be a faulty hardware/driver, but it made me re-think some stuff in the interface.

None of these changes should modify normal behavior (assuming good BT connection)

3 things in this PR:

Refactor:
Extracted magic/hardcoded numbers to defines (for future unification with ESP SerialBLEInterface)

Slave latency:
With slave latency = 4: The peripheral can skip up to 4 consecutive events and only wake up on the 5th event (or earlier if it has data to send)
Slave latency only applies when both devices have nothing to send.
Lower power: Less BT radio-on time / lower CPU usage
Less frequent BLE interrupts

Queue throttling on error:
If our queue is full we keep hammering with full speed.
Our queue being full 99% of the time means spotty BT connection (other 1 percent is if we want to send a lot of data, but that should clear up in 1 or 2 tries)
Serialbleinterface now throttles down retries to every 250msec with queue full, until the queue is starting to move again (or the BT connection times out ofc)

[liquidraver]

@oltaco you have good eyes for code review too, can you glance on this? thx