Provide inherent trait impl `impl<C: Controller> Controller for &C {...}`

[ivmarkov]

Most trait crates do provide these (either the &mut variation, or the non-mut one or both) as this increases the usability of the traits.

Notes:

• Might need to provide the impl for ControllerCmdSync and ControllerCmdAsync as well
• Might need to provide this for the blocking Controller trait as well
• Open question: since this is a breaking change, shall we switch to the async syntax then?

Most important is that these impls cannot be provided if the external embedded_io::ErrorType is used, as it only has a &mut impl:
impl<T: ErrorType> ErrorType for &mut T {...}.

I would suggest that we use our own, bt-hci-specific ErrorType then but possibly still make use of embedded_io::Error?

[ivmarkov]

Just to mention that in the meantime, I just use a newtype so as to be able to use a &Controller as a Controller.

This is a long, laborious workaround, which is essentially repeating the scope of what it would take to fix this issue, but with that said - it works fine (why shouldn't it?).

So in a way my workaround is a proof that providing inherent trait impl impl<C: Controller> Controller for &C {...} would work just fine for users.

[alexmoon]

That seems reasonable. PR welcome.

[ivmarkov]

That seems reasonable. PR welcome.

If we do this (which would be a breaking change BTW that needs a minor version increment) I wonder:

• If we should change all &self to &mut self? A bit like the reasoning here. Note that Controller implementations "FooController" that naturally support interior mutability can still impl Controller for &FooController so nothing is lost. That would actually take care of the pesky problem where ErrorType can no longer be used with the future inherent impl, as it will be for &mut
• Switch to async-fn-in-trait?

Perhaps I'm missing the reason why the hci traits (a) take &self instead of &mut self and (b) use the -> impl Future syntax?

[alexmoon]

* If we should change all `&self` to `&mut self`? A bit like the reasoning [here](https://github.com/rust-embedded/embedded-hal/pull/547). Note that Controller implementations "FooController" that naturally support interior mutability can still `impl Controller for &FooController` so nothing is lost. That would actually take care of the pesky problem where `ErrorType` can no longer be used with the future inherent impl, as it will be for `&mut`

The Controller uses shared references because typical usage involves concurrent tasks doing some combination of reading packets, writing data, and executing commands. Because those activities are expected to be concurrent, synchronization must happen within the Controller implementation, which can also allow for optimization in some controller implementations that might not need to synchronize between (for example) read and write activities.

* Switch to `async-fn-in-trait`?

impl Trait is recommended for trait definitions because it allows specifying lifetime and Send/Sync constraints that the async fn syntax does not. async fn is fine for trait implementations.

[ivmarkov]

Agreed on the first, not really that opinionated for the second.

Will open a PR once I have a free one hour.