Add async API for CAN

[liamkinne]

Adds a new CAN trait with both async and fallback non-blocking methods.

Module is named asynch to avoid a collision with the async keyword. Alternatively a separate crate embedded-can-async could be published.

[burrbull]

Strange signature.

[liamkinne]

Inspired by a pattern I've seen around like here: https://docs.rs/rtic-sync/latest/rtic_sync/arbiter/struct.Arbiter.html

Can just get rid of it, but I think it's useful.

[adamgreig]

Thanks for the PR! We had a brief discussion about it in the weekly meeting today. Having the trait in the asynch module is fine. I think the only remaining question is whether to keep the try_x() methods, move to to another trait, or delete them entirely.

It looks like either the crate's MSRV (and related CI tests) will need updating, or the trait needs to be gated, to get CI passing, too.

[liamkinne]

@adamgreig thanks for the update.

I'm still strongly for keeping the try methods. The use case is that when libraries (bxcan, fdcan, etc) implement these traits they can only implement one trait at a time so they will have a blocking client and an async client. If you're using the async client but need to do something in a non-async context (think RTIC hardware task) you need something to fallback to that doesn't require .await.

It is very similar to the ideas around nb but more like "hey this method will work first time most of the time, unless your buffer is full which you can chose how to handle".