util: parameterize mutex blocking behavior

[hawkw]

this was originally suggested by @jamesmunns in a comment on #191:

Misc note (can totally be a future PR): It might be nice to be able to modify the lock behavior somehow.

For me, any lock contention is likely to be a programming bug, so .try_lock().unwrap() is likely to make a "louder"/easier to catch case for me.

Originally posted by @jamesmunns in #191 (comment)

i think the nicest way to do this is add some kind of trait to mycelium_util that represents how a lock would block, and make it generic over a type parameter of that trait. by default, it can spin, but with the appropriate marker type, a lock could be configured to panic any time it would block.

this could also be useful for passing in a platform-specific way to disable interrupts while a lock is held, as discussed in #88.

[hawkw]

I'm not actually sure if doing this using a trait is the best approach. You would ideally want to be able to disable spinlocks in dependencies as well as your own code (e.g. in maitake), and if this was done using a trait, libraries using mutexen would need to parameterize basically everything in the library over that trait. In some cases, such as when the mutex is in a static internal to the library, this can't be done that easily.

Perhaps a better approach would be to introduce a RUSTFLAGS cfg like mycelium_util_single_core or something that internally changes the mutex behavior. It would have to be set via RUSTFLAGS rather than via a feature flag, since we would only want the top level project (the OS/app) to set it, and not have library dependencies set it.

Unfortunately, this approach would probably not work for #88, but it would give us a way to disable spinlocks on single-core-only targets.

@jamesmunns what do you think?