`no_std` support

[GregoryConrad]

With #46, we will no longer have concread. Thus, it should now be possible to support no_std (either via BTree or via a simple hash based hashmap/hashset--do a benchmark)

[GregoryConrad]

I've realized a few things while working on this:

• we cannot use a no-std hash(map/set); I originally thought HashDOS would not be an issue since capsules are defined at compile time, but I since realized that dynamic capsules can be keyed based on arbitrary user input, which opens the door to that attack
• Thus, we are stuck with BTree(Map/Set) if we want no-std. Not a big issue, but CapsuleKey would have to change from Hash to Ord (or PartialOrd--I'd have to check). But that feels a little restrictive when compared to Hash.
• Integrating lock_api directly to be generic over the specific implementation of the lock is awful. The generics infect nearly every single type in the rearch crate, to the point where I wonder if it is worth it at all. Possible? yes. But it really is ugly and I don't like it from a maintainability perspective.

Due to the above, closing this as a won't-fix for now, although I really would like to have no_std support 😕

[GregoryConrad]

Integrating lock_api directly to be generic over the specific implementation of the lock is awful. The generics infect nearly every single type in the rearch crate

Thought about this a bit a few days ago. If we had module generics then this would be fine (i.e., mod rearch<T: SomeLockApiThing, U: AnotherThing> {...}). Unfortunately, they're not a thing.

Also, ideally, I'd love to ditch the type-map that ReArch currently uses and instead generate a custom-made container definition at compile time. Maybe possible via a build.rs, but that is clunky. Not sure what Rust features would even be required to be able to implement that without code gen, but it certainly isn't possible in stable/nightly right now.

Even cooler with the compile-time container approach (other than reading capsules being a "free" operation), we could support:

• BTreeMap or HashMap or other for dynamic capsules
• Perhaps some sort of MVCC via a Cow approach + atomic switches
  • We would likely need to have atomics or something on each field since cloning entire container would be expensive