Consider `parking_lot`'s `RwLock` instead of concread

[GregoryConrad]

Currently, read/write locks are only held for a very short amount of time. I originally choose concread because it supports concurrent writers/readers (so reads always remain unblocked), but I'm not sure it actually helps our specific benchmarks. One example is when a capsule is not initialized, you will need to grab a write, which is blocking.

The specific issue I'm facing with concread is that I can't support a Container::read_ref api with it right now. I'd need the ability to commit a write txn, and in that process, downgrade it to a read txn. I may file an issue over at concread to see if they'd support this, but if parking_lot's RwLock around a standard HashMap is faster anyways, I'm not sure it'd be worth it, as they support downgradable writes.

[GregoryConrad]

Also should consider:

• BTreeMap + BTreeSet instead of hash-based equivalents
• And if the above is similar performance, consider seeing how integrating with lock_api is for no_std (but with alloc) support!

[GregoryConrad]

Based on the count benchmark in /examples (which isn't scientific by any stretch of the imagination), I got the following results. Perfect? No. Good enough to show trends and make architectural decisions? Probably, yes.

As you may predict, concread supports a large number of readers better. However, the RwLock with HashMap variant is faster for a smaller number of readers, and is always faster for writers. So the proper choice here is likely to depend upon the expected workload.

I'll sleep on this and see what I think later.

[GregoryConrad]

I am originally inclined to say that I am tempted to ditch concread, because:

• This more easily opens the doors for no_std
• Concread reads per second are significantly higher, but does this actually matter for a typical workload? I have a feeling most uses of ReArch may be on a server where you're interacting over some form of I/O, which I'd have to guess under most situations wouldn't be hitting that many reads per second anyways.
• The writes per second can definitely be hit on a target server workload. Thus, if we can squeeze more writes out here, we may want to.

[GregoryConrad]

Also, if we do go down the no concread route, we will want to add in the container.read_ref method

[GregoryConrad]

Going to remove concread. Need to still add the Container::read_ref api.