Initial support for the Rust Embedded embedded-hal

[alistair23]

This is very initial support for the embedded_hal [1]. This allows general embedded Rust crates to be built on top of libtock-rs with minimal porting effort.

This currently just stubs out the support and implements the digital::OutputPin trait for GPIO pins.

1: https://docs.rs/embedded-hal/1.0.0/embedded_hal/index.html

[alistair23]

I'm not sure whether it would perhaps not be better to ship this as a separate crate. We can't extend libtock-rs' types in other crates, but we can introduce wrapper types that then implement the embedded HAL. I'm slightly skeptical of sprinkling these #[cfg( attributes throughout the conference, as it can become quite hard to reason about the various interactions and interface compositions across permutations of features.

A separate crate is probably the way to go. One of the issues we have is that libtock-rs uses types, which don't work very well.

For examples, for the SPI work I have this

#[cfg(feature = "rust_embedded")]
impl<S: Syscalls, C: Config> embedded_hal::spi::SpiDevice for SpiController<S, C> {
    fn transaction(
        &mut self,
        operations: &mut [embedded_hal::spi::Operation<'_, u8>],
    ) -> Result<(), Self::Error> {
...

Then following the standard libtock-rs style we have

pub mod spi_controller {
    use libtock_spi_controller as spi_controller;
    pub type SpiController = spi_controller::SpiController<super::runtime::TockSyscalls>;
}

But that results in errors like this when trying to actually use the type

93 |     let di = SPIInterface::new(SpiController, dc);
   |                                ^^^^^^^^^^^^^
   |
   = note: can't use a type alias as a constructor

Wrapper structs in a crate should help with that. I think this PR is still ok as a first step. Any thoughts on the way to setup the crate are appreciated

[alistair23]

Is this ready to merge now?