Regression found with the newly added FAT{12|16|32} support

[azayet01]

Assuming the following YAML section to generate the image :

actions:                                                                                                 
  - action: image-partition
    imagename: {{ $target }}-{{ $variant }}.img
    imagesize: 4G
    partitiontype: gpt
    partitions:
      - name: bios
        fs: fat32
        start: 0%
        end: 2MB
        flags: [ bios_grub ]
      - name: efi
        fs: fat32
        start: 2MB
        end: 200MB
        flags: [ boot, esp ]
      - name: boot
        fs: ext4
        start: 200MB
        end: 400MB
      - name: root
        fs: ext4
        start: 400MB
        end: 100%
    mountpoints:
      - mountpoint: /boot/efi
        partition: efi
      - mountpoint: /boot
        partition: boot
        options: [ x-systemd.automount ]
      - mountpoint: /
        partition: root

With fs set to fat32, the partitions are not mounted after creating and formatting the partitions.
It use to work but then after a rebase, some few changes introduced the regression.

After investigation, I found the culprit commit :
commit 94fedb2
Date: Tue Mar 19 17:43:42 2024 +0000
actions: image-partition: enable creation of FAT{12|16|32} partitions

This one added more options when it comes to creating FAT partitions. So when partition fs is defined as "fat", "fat12", "fat16", "fat32", "msdos" or "vfat", then mkfs.vfat is used to create the partition, and different options were used depending on the FAT type.

The main issue is that mounting a FAT partition should use "vfat"
as fs type when using syscall.Mount().

So, in order to fix this issue, "vfat" is simply used to mount "fat", "fat12", "fat16", "fat32" or "msdos" partitions.
I created a pull request with a proposed fix here.