Kernel+Userland: Introduce loop devices
This PR introduces loop devices. Loop devices are plain simple block devices that are used to direct IO on an Inode and represent it as a block device, so it could be used for filesystem mounting like any other block device, for example.
Essentially speaking, this allows us to mount regular files that have a filesystem image within them. We had this feature in the past but I removed it because it was clunky to use, so loop devices are a neat and simple mechanism to handle this situation.
No special syscalls were added - I added 2 ioctl options to the /dev/devctl device node to create and remove loop devices.
Ofc, it comes with 2 new special utilities to add and delete such devices. In addition to that, now mount(8) can automatically detect that the source for a mount procedure is not a block device, and therefore prepare a temporary loop device to mount the filesystem from that file.
As for more technical kernel details, it's possible to use this mechanism as a temporary way to get access to filesystems in regular files - you can mount the filesystem and get rid of the loop device with no negative impact on the system.
~~Please note that there's a thing called LoopDevice::InodeContext - I use it to ensure you can't create 2 different block devices from the same Inode, as it will allow you to create 2 different FileSystem instances that point to the same Inode - which could easily lead to filesystem corruption. I introduced this class as a preparation for #22968, because in my vision what we would have is loop devices that are private to each container environment, but you can't technically share an LoopDevice::InodeContext as the contexts will still be stored in a global list (but each LoopDevice will be attached to a list on the container VFSRootContext object).~~
It looks like your test fails on your branch with clang, looking at the logs. can you verify that this works in that config?