Wireless Paper: Fix BLE after Lightsleep

[todd-herbert]

1. Refactor NimBLE deinit
   NimBLEDevice::deinit() is used with Wireless Paper to achieve low current during deep-sleep (1mA -> 18µA).
   Previously called for both deep-sleep and light-sleep. Unable to re-init BLE after light-sleep. Bluetooth broken.

   Changes implemented:

   • NimBLEDevice::deinit() called only for deep-sleep.
   • "De-init during deep-sleep" behavior now set with macro in variant.h: NIMBLE_DEINIT_FOR_DEEPSLEEP. Currently enabled only for Wireless Paper.

   Result:

   • BLE working after light-sleep
   • Light-sleep current increased

(reverted)

2. LED Blink disabled during light-sleep (Wireless Paper only)
   Without NimBLEDevice::deinit(), Wireless Paper BLE hardware has a prolonged run-down. After ~30 seconds, current stabilizes at ~13mA (compared to immediate 12mA with deinit).
   Previously, light-sleep would wake every 30 seconds to blink the LED. This caused Wireless Paper to spend significant time in inefficient "run-down" phase.

   Mean current during a light-sleep period of a given duration.
   
   A singe 180s sleep consumes 25% less power than 6 x 30s sleeps.

   Changes:

   • Wireless Paper will not wake to blink LED during light-sleep.
   • New "no blink" behavior enabled with macro in variant.h: LS_NO_BLINK

   Result:

   • Moderate reduction in light-sleep power consumption.

[DWizzy]

I assume there's been a discussion about the LED blink. I would love to hear the thoughts! Personally I would prefer disabling the blinking

[todd-herbert]

@DWizzy In this particular case, the blinking being referred to is a specific behaviour during power-saving, where the device wakes briefly every 30 seconds. It blinks the LED at this time, but more importantly, it handles other scheduled tasks. Stuff like telemetry, range test etc.

Without this brief wakeup, the device may very well stay asleep for hours or longer by default, depending on the device role (client, router, etc.), which might be undesirable.

This is all speaking about the one specific behavior during power saving. Discussion about disabling the blinking generally is another matter.
I personally think it would be a nice option, and would be happy to write some of the code, but as implementing new settings is a co-ordinated effort between people working on different parts of the project, it would need to get the official green-light first.

Someone opened a feature request just the other day. Could be good to rally some support over there? #3635