Note that install_bootloader calls guess_mounts which mounts both the
real and pseudo-filesystems, so there is no need to mount the pseudo-
filesystems again.

- ask for encryption key
- add enabled dmcrypts to the list of partitions to look at

After commit c2fcfde5b3064845d96f7cb29ddc27689ea6e710, mounting eg:
exfat strangely fails as it doesn't automatically load exfat.
(I suspect it's a bug either in exfat.ko or in util-linux)

And also display a shorter distribution name (eg: "Mageia (Cauldron)"
which is still longer than just "Mageia").

history:
commit fd8bbba2f02b8bccd69e67c326fd320c0827941d wrongly introduced a
"%s" in place of "Mandriva" (w/o adding any argument)

Then commit e95388927be1f0de67413bdb5430cf0031710f54 fixed it by
replacing "%s" with the displayed release info at end.

However commit 3928e119899ee844bc0ac90e963d913782b8ae9c enables us to
have the info we want, so just use that

Instead of doing brute force guessing.
Thus making logs easier to read…
Also slightly faster and less error-prone (even if no true FS should
havoc on another fs type).

We could have fallbacked on ->{fs_type_from_magic} but that would only
help iso9660 & the like which are not true FSes such as tested
previously by fs::type::true_local_fs_types()

it was wrongly added in commit 7cd51d36c05a66555b07a7fa850b21686ded2e1a

The issue is that lsparts is relying on fs::proc_partitions::read_raw(),
which reads /proc/partition which reports size of devices in 1kb blocks
instead of expected 512b sectors elsewhere...

The size is adjusted by *2 in read() but lsparts only used the lower
level interface.

This bug was introduced in commit 20e553d8f0ead3d5de1fb61d1aa255dd35549cf2