Implement partial embedded_can 0.4 compatibility (id conversions, transmit, receive)

[projectgus]

Relevant to #44. Was working with another third party crate that used embedded_can types and Id conversions in particular were a pain, so decided to jump in and try to add some support here.

In this PR:

• Implements From and Into embedded_can id types for fdcan id types. My initial approach was to actually type alias embedded::can::{Id, StandardId, ExtendedId} to their fdcan equivalents if the feature flag was enabled (branch here). This works as the types are drop-in replacements for each other, but feels a little risky and I couldn't make the docs generate cleanly. In my project, swapping to this version meant adding some into()s but didn't add any code size as the conversions are trivial and optimise away.
• Adds new transmit_frame() and transmit_preserve_frame() functions which behave the same as transmit_frame() and transmit_preserve() but accept an embedded_can::Frame.
• Adds new receive_frame(), receive0_frame() and receive1_frame() functions which behave the same as receive() but construct a new embedded_can::Frame-implementing type.

Not in this PR:

• Support for CAN-FD, as embedded_can doesn't yet support it. See https://github.com/rust-embedded/embedded-hal/issues/578.
• Support for embedded_can::Error.
• Support for trait Can. These require an associated type so IIUC not quite compatible with the current APIs. (Also, for my application I chose to split the structs into Rx and Tx so I didn't look that closely at these.)
• Generated docs, apart from the one-liner. I'm not sure what the best practice around including feature-gated things like this in the crate docs are...?

[projectgus]

Marking as a draft because I haven't tested the receive functions yet.