rust: no_std support

[Sympatron]

The Rust crate currently depends heavily on std. Since OSDP is a protocol mostly for embedded devices I think no_std support is necessary.

This PR adds that support by:

• Using core::* and alloc::* types instead of std::* where possible.
• Defining a feature "std", which users can opt out of. Things like UnixChannel or the file API will not be available then.
• Using parking_log and spin as a replacement for std::sync::Mutex. I chose parking_lot, because it is widely used, cross platform and supports lock_api and can therefore be used just like spin::Mutex for no_std without any changes. The use of spin should be temporary, because this is almost never what you really want. In the future we should probably let the user choose the concrete Mutex implementation that makes sense for their platform. I didn't do this, because I wanted to keep the changes backwards compatible for now.
• Defining custom Read and Write traits instead of std::io::{Read, Write}, because the latter is not no_std compatible. I couldn't just replace them with embedded_io::{Read, Write} either, because those are not object safe and can therefore not be used with Box<dyn ...>. My traits are just very thin wrappers around the others with blanket implementations for everything implementing std::io::{Read, Write} or embedded_io::{Read, Write}.

I am open for discussion about my decisions in this PR. :)

[sidcha]

Thank you for the PR @Sympatron. no_std support is here earlier than I anticipated. :) Let me take a look.

[sidcha]

Looks good to me, thanks for the PR.

[sidcha]

Shouldn't we have an explicit

#[cfg(feature = "std")]
use parking_lot::Mutex;
#[cfg(not(feature = "std"))]
use spin::Mutex;

insread of importing from crate::? It's confusing as it appears as though we are providing a mutex type.

[Sympatron]

You are right. This feels wrong. I wanted to have the Mutex selection only in one place, but I agree this was not the best solution.

I solved this now, by using Arc instead of Mutex in lib.rs.

[sidcha]

I think we can have a no_std compliant file implementation as well. Was this left out just for simplicity or is there a design problem?

[Sympatron]

I don't know of any way to solve this generally without std so I left it out. I think it would make more sense to let the user handle that themselves in the command callback.

[sidcha]

I am in the middle of the -sys crate split. I guess it makes sense to merge this and then do the split (otherwise this branch would have way too many conflicts). I will fix any fallouts from this change post merge since no one is using this create ATM.

[Sympatron]

Sounds good. I just pushed a fix to your comment about Mutex.