Support multiple cryptroot= devices.

Created by: sbrudenell

I use btrfs on multiple LUKS-encrypted disks. In order to support single password entry, I have a keyfile that is a LUKS-encrypted image that, once decrypted, also decrypts the other volumes.

I made some changes to init to support this. I feel they're in line with the current design and don't interfere with other use cases. Let me know if I should make any changes to support this goal.

1. cryptkey=... has special behavior if the key matches *.img: We'll treat it as a LUKS-encrypted file (with embedded header), and try to unlock it. We use the unlocked key as a later cryptkey argument. Note: I couldn't figure out a way to get nlplug-findfs to do this with a single invocation, so I invoke cryptsetup directly, so it needs to be included as a feature. However I still need to invoke nlplug-findfs to do hotplugging, for e.g. USB keyboards to enter the passphrase, so I do a "no-op" nlplug-findfs.

2. cryptroot=... supports multiple arguments. If multiple arguments are detected, we unlock each explicitly with nlplug-findfs.

3. We now support multiple entries of a single argument, e.g. cryptroot=UUID=a cryptroot=UUID=b. This will accumulate the arguments joined by whitespace, such that KOPT_cryptroot="UUID=a UUID=b". This matches the way one passes multiple arg entries to the kernel, so hopefully it makes sense to users.

Note: I made change 3 really because the apparent intended use was broken for me. Code comments imply that I should be able to pass cryptroot="UUID=a UUID=b". I did this in my grub.cfg and verified it in the command list at boot time, but once booted, /proc/cmdline looked like ... "cryptroot=UUID=a UUID=b" ..., and init did not parse this as intended. I'm not sure if this is a known bug. I'm using grub-efi-2.02-r14 and linux-vanilla-4.19.41-r0.