bluetooth: switch to btleplug

[webbeef]

btleplug depends on tokio so we use a bridge thread to interface with Servo thread based messaging.
We keep feature parity except for BtleplugGATTService::get_includes() that will require upstream implementation.
In terms of OS support, I verified on Linux and MacOS. Android is untested, but btleplug claims support.

Testing: No test failures, green try run at https://github.com/webbeef/servo/actions/runs/23390850825
Fixes: #43254.

[webbeef]

The JNI bump in btleplug is discussed here: deviceplug/btleplug#416

[qdot]

Wait. Servo is using btleplug? If so, we can prioritize our jni upgrade.

[webbeef]

Wait. Servo is using btleplug? If so, we can prioritize our jni upgrade.

That would be wonderful. Because just bumping the version number is not enough 🥲

[qdot]

@webbeef Ok, well, deviceplug/btleplug#462 passes all of our embedded device tests for android. I've got a lot more testing to do on it in our applications before it lands, and there's also some policy questions around Servo AI code acceptance (even though this is a dependency). This upgrade wasn't happening without sort sort of help (no one on the project knows how the JNI works, see https://nonpolynomial.com/2023/10/30/how-to-beg-borrow-steal-your-way-to-a-cross-platform-bluetooth-le-library/, and no one has touched it since it originally came in, hence the 5 years out of date library), so that may need to be reckoned with.

[sagudev]

there's also some policy questions around Servo AI code acceptance (even though this is a dependency)

We already use wgpu, vello, and some mozilla stuff and they all allow use of AI, so this should be no problem.