machine/mutex.h: Sprinkle sys/types.h, omit machine/lock.h.

Turns out machine/lock.h is not needed for __cpu_simple_lock_t, which
always comes from sys/types.h. And, really, sys/types.h (or at least
sys/stdint.h) is needed for uintN_t and uintptr_t.

machine/mutex.h: Sprinkle includes so this can be used by crash(8).

XXX pullup-10

- In kern_mutex.c, if MUTEX_CAS() is not defined, define it in terms of
atomic_cas_ulong().
- For arm, ia64, m68k, mips, or1k, riscv, vax: don't define our own
MUTEX_CAS(), as they either use atomic_cas_ulong() or equivalent
(atomic_cas_uint() on m68k).
- For alpha and sparc64, don't define MUTEX_CAS() in terms of their own
_lock_cas(), which has its own memory barriers; the call sites in
kern_mutex.c already have the appropriate memory barrier calls. Thus,
alpha and sparc64 can use default definition.
- For sh3, don't define MUTEX_CAS() in terms of its own _lock_cas();
atomic_cas_ulong() is strong-aliased to _lock_cas(), therefore defining
our own MUTEX_CAS() is redundant.

Per thread:
https://mail-index.netbsd.org/tech-kern/2021/07/25/msg027562.html

Nix now-unused definitions of MUTEX_GIVE/MUTEX_RECEIVE.

branches: 1.1.18; 1.1.22;
New files for OR1K support

machine/mutex.h: Sprinkle includes so this can be used by crash(8).

XXX pullup-10

- In kern_mutex.c, if MUTEX_CAS() is not defined, define it in terms of
atomic_cas_ulong().
- For arm, ia64, m68k, mips, or1k, riscv, vax: don't define our own
MUTEX_CAS(), as they either use atomic_cas_ulong() or equivalent
(atomic_cas_uint() on m68k).
- For alpha and sparc64, don't define MUTEX_CAS() in terms of their own
_lock_cas(), which has its own memory barriers; the call sites in
kern_mutex.c already have the appropriate memory barrier calls. Thus,
alpha and sparc64 can use default definition.
- For sh3, don't define MUTEX_CAS() in terms of its own _lock_cas();
atomic_cas_ulong() is strong-aliased to _lock_cas(), therefore defining
our own MUTEX_CAS() is redundant.

Per thread:
https://mail-index.netbsd.org/tech-kern/2021/07/25/msg027562.html

Nix now-unused definitions of MUTEX_GIVE/MUTEX_RECEIVE.

branches: 1.1.18; 1.1.22;
New files for OR1K support

- In kern_mutex.c, if MUTEX_CAS() is not defined, define it in terms of
atomic_cas_ulong().
- For arm, ia64, m68k, mips, or1k, riscv, vax: don't define our own
MUTEX_CAS(), as they either use atomic_cas_ulong() or equivalent
(atomic_cas_uint() on m68k).
- For alpha and sparc64, don't define MUTEX_CAS() in terms of their own
_lock_cas(), which has its own memory barriers; the call sites in
kern_mutex.c already have the appropriate memory barrier calls. Thus,
alpha and sparc64 can use default definition.
- For sh3, don't define MUTEX_CAS() in terms of its own _lock_cas();
atomic_cas_ulong() is strong-aliased to _lock_cas(), therefore defining
our own MUTEX_CAS() is redundant.

Per thread:
https://mail-index.netbsd.org/tech-kern/2021/07/25/msg027562.html

Nix now-unused definitions of MUTEX_GIVE/MUTEX_RECEIVE.

branches: 1.1.18; 1.1.22;
New files for OR1K support

Nix now-unused definitions of MUTEX_GIVE/MUTEX_RECEIVE.

branches: 1.1.18;
New files for OR1K support