Add support for no_std targets

[remimimimimi]

Support for #[no_std] targets will be pretty convenient in kernel development.
For #[no_std] syncronization primivitves spin crate can be used respectively.

[bertptrs]

Interesting. I took a quick look around the code base for things that would not work with no_std as-is, and I came up with the following:

• The Directed Acyclic Graph implementation heavily leans on HashMap and HashSet for its data structure. This could be replaced with hashbrown, which could be a good idea in general as it's a little faster than the std implementation.
• Internal locking is currently handled through a normal std::sync::Mutex, but as you mentioned this could be replaced with spin when that is not available.
• Bookkeeping for the current locks held is done with a thread_local! macro. There is no no_std equivalent for this as far as I'm aware, so that would still require some research.

[remimimimimi]

About thread_local! I think, that we can wrap value in atomic and remove macro for now.

[bertptrs]

I'm not sure it'll work like that; the thread_local keeps track of the currently held mutexes for each individual execution thread. In no_std there's no such abstraction available.

Of course, you could ignore the execution threads altogether and just use a single global list of currently held mutexes, but that doesn't really make sense unless you have no concurrency. In that case deadlocks aren't really a thing anyway.

Fundamentally I think the kind of concurrency you have in your no_std environment will determine what kind of tracking primitive you need. I don't think there's a general solution to this, and I'm not familiar enough with the no_std scene to know what the major conventions are, here.