Proposal, again: Disable autoload of compat_xyz modules

[Maxime Villard <max%m00nbsd.net@localhost>]

I recently made a big set of changes to fix many bugs and vulnerabilities in
compat_linux and compat_linux32, the majority of which have a security impact
bigger than the Intel CPU bugs we hear about so much. These compat layers are
enabled by default, so everybody is affected.

Secteam is in a state where no one is willing to pull up all the changes to
the stable branches, because of the effort. No one is willing to write a
security advisory either. When I say "no one", it includes me.

The proposal and discussion held in this 2017 thread still hold and are
unchanged two years later:

	https://mail-index.netbsd.org/tech-kern/2017/07/31/msg022153.html

The compat layers are largely untested, often broken, and are a security risk
for everybody. Keeping them enabled for the <1% users interested means keeping
vulnerabilities for the >99% who don't use these features.

In the conversation above, we hit the problem that there was cross-dependency
among compat modules, and we couldn't selectively disable specific layers.
Today this is possible thanks to pgoyette's work. That is, it is possible to
comment out "options COMPAT_LINUX" from GENERIC, and have a compat_linux.kmod
which will modload correctly and be able to run Linux binaries out of the box.
Under this scheme, the feature would be only one root command away from being
enabled in the kernel.

Therefore, I am making today the same proposal as Taylor in 2017, because the
problem is still there exactly as-is and we just hit it again; the solution
however is more straightforward.