cgd(4): Omit technically-correct-but-broken adiantum dependency again.

It is true that cgd_crypto.c depends on sys/crypto/adiantum now, and
transitively on sys/crypto/aes.

However, there's a problem with the cgd module having a formal
(transitive) module dependency on the aes module.

Yesterday I thought the problem with this was that fpu_kern_enter was
artificially restricted while cold -- to detect, and noisily crash
on, reentrance, it raises the IPL to IPL_VM, asserts that the IPL is
not _higher_ (so it can't be re-entered by an IPL_SCHED or IPL_HIGH
interrupt), and asserts that it's not currently in use on the current
CPU.

Early at boot, the IPL is at IPL_HIGH, and no interrupts are possible
anyway, so the assertions tripped for artificial reasons, which I
fixed in:

https://mail-index.netbsd.org/source-changes/2022/04/01/msg137840.html

However, I had forgotten that there's a deeper problem for the cgd
module dependency on aes.  The ordering of events is:

1. Initialize builtin MODULE_CLASS_DRIVER modules -- including cgd.

2. Run configure -- including detecting CPUs, which on aarch64 is
   where the decision of which AES (and ChaCha) implementation to use
   based on supported CPU features.

3. Initialize builtin MODULE_CLASS_MISC modules -- including aes,
   _if_ there are no driver-class modules that depend on it.

There's a tangle of ordering dependencies here:

- MODULE_CLASS_DRIVER modules providing _autoconf_ drivers generally
  have to be initialized _before_ configure, because you need the
  driver to be initialized before configure can attach its devices.

- configure must run _before_ aes is initialized because the decision
  of which AES implementation to choose depends on CPU features
  detected in configure, and the prospect of dynamically changing the
  AES implementation is too painful to contemplate (it may change the
  key schedule, so it would invalidate any existing key schedules
  precomputed by callers like uvm_swap or configured cgd devices,
  which raises a host of painful concurrency issues to invalidate
  these cached key schedules on all CPUs in all subsystems using
  them).

- cgd doesn't figure into the configure stage of autoconf, but it
  nevertheless has to be MODULE_CLASS_DRIVER because specfs autoloads
  MODULE_CLASS_DRIVER modules in case they provide _devsw_ drivers
  (i.e., /dev nodes), as cgd does.  And we don't have a mechanism for
  identifying `autoconf driver modules' separately from `devsw driver
  modules' because some modules provide both and each module can have
  only one class.

For now, this is breaking boot on several tier I architectures so
let's nix the cgd->adiantum->aes module dependency as a stop-gap
measure.

sys/dev/cgd.c

@@ -1,4 +1,4 @@
-/* $NetBSD: cgd.c,v 1.145 2022/04/01 21:09:24 pgoyette Exp $ */
+/* $NetBSD: cgd.c,v 1.146 2022/04/02 09:53:20 riastradh Exp $ */
 
 /*-
  * Copyright (c) 2002 The NetBSD Foundation, Inc.
@@ -30,7 +30,7 @@
  */
 
 #include <sys/cdefs.h>
-__KERNEL_RCSID(0, "$NetBSD: cgd.c,v 1.145 2022/04/01 21:09:24 pgoyette Exp $");
+__KERNEL_RCSID(0, "$NetBSD: cgd.c,v 1.146 2022/04/02 09:53:20 riastradh Exp $");
 
 #include <sys/types.h>
 #include <sys/param.h>
@@ -1723,7 +1723,7 @@ cgd_selftest(void)
 	aprint_debug("cgd: self-tests passed\n");
 }
 
-MODULE(MODULE_CLASS_DRIVER, cgd, "adiantum,blowfish,des,dk_subr,bufq_fcfs");
+MODULE(MODULE_CLASS_DRIVER, cgd, "blowfish,des,dk_subr,bufq_fcfs");
 
 #ifdef _MODULE
 CFDRIVER_DECL(cgd, DV_DISK, NULL);