some TODO items

While writing reform-handbook#2 and trying out whether I was writing down works I identified some wrinkles in how the tools work. I'm going on holidays for 10 days, starting 2022-06-22, so I'm writing down what I found so that I don't forget and so that maybe others can work on it while I'm away. In https://community.mnt.re/t/encrypted-nvme-boot-from-emmc-confusions/884/12 @megasquid offered to help, so I'm mentioning them here.

1. before mounting filesystems and especially before flashing emmc, the tools should check if the partitions or emmc are in use or not and abort if they are in use. One possible way to do this is to run lsblk --noheadings --output=MOUNTPOINT /dev/XXX which will output all active mountpounts and thus this output must be empty.
2. currently, reform-migrate just calls reform-boot-config without the --emmc option (which means it will modify /boot on the sd-card) but maybe the person running reform-migrate wants to modify /boot on emmc. The reform-migrate script should either get an --emmc option itself or ask the user whether they want to modify /boot on sd-card or emmc
3. reform-setup-encrypted-nvme calls reform-migrate but again without asking whether /boot from sd-card or emmc should be used. After fixing the last point, reform-setup-encrypted-nvme has to be adjusted in a similar fashion
4. if the user chooses --emmc for /boot in any of the tools, they should be informed that their DIP switch has to be set to OFF or otherwise it will boot from the sd-card
5. reform-setup-encrypted-nvme modifies /etc/fstab, /etc/crypttab and /etc/initramfs-tools/conf.d/resume of the currently running system before running reform-migrate. Instead, reform-setup-encrypted-nvme should first run reform-migrate and then modify those files on the target path. The problem here is that reform-migrate will already have called reform-boot-config and after modifying these files we have to run reform-boot-config which is just a waste of cpu-cycles. Also it's inelegant to have reform-migrate first mount and then unmount the target path only such that we have to do the same thing again. Maybe reform-setup-encrypted-nvme should just copy the rsync call and we accept some code duplication in favour of not running reform-boot-config multiple times?
6. reform-boot-config currently can only switch between sd, emmc and nvme for the rootfs and allows overwriting that by setting the ROOTPART environment variable. This is not a good interface as it's very confusing to set a root device using ROOTPART but then also put sd (which will be ignored) as the positional argument. A more intuitive interface would be nice.
7. u-boot can not only boot from emmc and sd-card but also from a usb-medium. Should the --emmc switch be turned into a --boot={emmc,sd,usb} switch or should we just ignore the fact that in theory we are also able to boot from usb? Maybe we should do the latter and let those users that want to do it for usb go the manual route in favour of keeping the tools simple?