kernel/mutex: Spinlockify
kernel/mutex: Spinlockify

Use a subsystem lock, not a per-object lock.  Really we want to lock
at mutex granularity where possible, but (1) that has non-trivial
memory overhead vs. e.g. directly spinning on the mutex state and (2)
the locking in a few places was originally designed to protect access
to the mutex *owner* priority, which is not 1:1 with a single mutex.

Basically the priority-inheriting mutex code will need some rework
before it works as a fine-grained locking abstraction in SMP.

Note that this fixes an invisible bug: with the older code,
k_mutex_unlock() would actually call irq_unlock() twice along the path
where there was a new owner, which is benign on existing architectures
(so long as the key argument is unchanged) but was never guaranteed to
work.  With a spinlock, unlocking an unlocked/unowned lock is a
detectable assertion condition.

Signed-off-by: Andy Ross <c70f9a6bf6ee0cd69c8af4ce5e6b131945769315@intel.com>

GiulianoFranchetto/zephyr,zephyrproject-rtos/zephyr,zephyrproject-rtos/zephyr,Vudentz/zephyr,finikorg/zephyr,GiulianoFranchetto/zephyr,finikorg/zephyr,ldts/zephyr,explora26/zephyr,Vudentz/zephyr,ldts/zephyr,galak/zephyr,GiulianoFranchetto/zephyr,finikorg/zephyr,nashif/zephyr,galak/zephyr,Vudentz/zephyr,finikorg/zephyr,Vudentz/zephyr,finikorg/zephyr,Vudentz/zephyr,nashif/zephyr,nashif/zephyr,explora26/zephyr,zephyrproject-rtos/zephyr,ldts/zephyr,galak/zephyr,galak/zephyr,GiulianoFranchetto/zephyr,ldts/zephyr,Vudentz/zephyr,zephyrproject-rtos/zephyr,explora26/zephyr,explora26/zephyr,nashif/zephyr,explora26/zephyr,galak/zephyr,zephyrproject-rtos/zephyr,nashif/zephyr,ldts/zephyr,GiulianoFranchetto/zephyr