I'm not sure if it's a good idea to change the size of kmutex_t. I
guess plenty of data structures have carefully been adjusted by hand
to its size and I don't know of any automatic way to recalculate that
stuff.
Even if not, since this is the only user and we probably won't have
that many of them even in the future, why not just define a new type

``rmutex'' which contains a kmutex, an owner and the counter? It
feels wrong to punish all the normal kmutex users for just one use.

It'll also make the implementation a lot simpler to test, since it's
purely MI.
"separate normal case and worst case"

Round two! Taking pooka's suggestion, this version is built on top of
(rather than beside) the existing non-recursive mutex. As such, it does
not affect any MD code.

Attached is a set of diffs that
1. Adds sys/sys/rmutex.h and sys/kern/kern_rmutex.c to implement
recursive adaptive mutexes. (Conspicuously missing is an rmutex(9)
man page... It will happen before this gets committed.)
2. Converts the existing module_lock from a normal kmutex_t to an
rmutex_t
3. Updates all of the (surprisingly many) places where module_lock
is acquired.

Compile-tested on port-amd64 (including rumptest). Since there are no
MD-changes in this version, there "shouldn't be" any issues with
building on other ports.

As previously noted, there is only one known use case for this so far:
modules loading other modules from within their xxx_modcmd() routine.
The specific use case we have involves loading the acpicpu driver/module
which eventually results in an attempt to load acpiverbose.