feat(bt): Add embassy trouble / bt_hci support

[Vollbrecht]

esp-idf-svc now provides an implementation of the bt_hci::Transport trait, enabling integration with the embassy-trouble Bluetooth stack.

This allows users to construct a ExternalController using the BtDriver and have it work seamlessly with embassy-trouble.

Three basic examples where added. For more checkout the examples in embassy-trouble/host

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo fmt command to ensure that all changed code is formatted correctly.
• I have used cargo clippy command to ensure that all changed code passes latest Clippy nightly lints.
• My changes were added to the CHANGELOG.md in the proper section.

[Vollbrecht]

Have to investigate why linking against the c6 failes. The vhci api in its form i am using is available in that form through all esp-idf version and targets that have ble radio. A bit busy today, will look deeper at the weekend.

[Vollbrecht]

Hmm, to my understanding in the esp32c6/h2 the underlying ble api is quite different. Even if they officially expose the bt hci api, it seams on older ESP_IDF versions not possible to:

• run in CONTROLER_ONLY mode and using the api on c6/h2, e.g i can link fine when enabling bluedroid alongside, though that defeats the purpose a bit and introduces a lof of bloat.
• the api itself is in kind of a wired as the same functions are now a "synchronize" api according to this issue .
• There are still recent changes to h2/c6 hci api in esp-idf that may even only allow to work with them correctly now on newer esp-idf versions looking here and here.

That all makes it currently much harder to support c6/h2. So either this PR stays blocked till i find how to fix the above or i simply exlude h2/c6 for now...

[ivmarkov]

Hmm, to my understanding in the esp32c6/h2 the underlying ble api is quite different. Even if they officially expose the bt hci api, it seams on older ESP_IDF versions not possible to:

• run in CONTROLER_ONLY mode and using the api on c6/h2, e.g i can link fine when enabling bluedroid alongside, though that defeats the purpose a bit and introduces a lof of bloat.
• the api itself is in kind of a wired as the same functions are now a "synchronize" api according to this issue .
• There are still recent changes to h2/c6 hci api in esp-idf that may even only allow to work with them correctly now on newer esp-idf versions looking here and here.

That all makes it currently much harder to support c6/h2. So either this PR stays blocked till i find how to fix the above or i simply exlude h2/c6 for now...

I wonder how esp-hal is capable of providing a bt-hci controller impl on every espressif chip using the espressif bt blobs, and somehow this is not possible when using these same blobs with esp idf?

[Vollbrecht]

They are not using this api, that i am using, but using a special low level api for the c6/h2. If you have a look here the btdm.rs is basically what we are also using here as an api and that is directly supported by esp-idf. For the h2/c6 they than use the npl.rs api, that i don't have any infos about.

[Vollbrecht]

This "controller only" problem, is also only one if you want to use not as an external controller but as a on chip controller not used by uart but via direct "ram" calls, that i seam to encounter on c6/h2.