cloud-init's cc_mounts module has outdated assumptions

# Bug report

Various issues:

## Cannot handle disk labels

Disk labels are commonly used today since the `/dev/sdX` name is not deterministic and the `/dev/disk/by-uuid/ffffffff-ffff-ffff-ffff-ffffffffffff` is long (and likely also kernel-specific). Cloud-init assumes that the first field must be a disk, which is not true.

## Cannot handle devices created after cc_mounts runs

This is the [documented and expected behavior](https://github.com/canonical/cloud-init/blob/94f58e8120e5dd077e4273f232a1f6128f8e3524/cloudinit/config/cc_mounts.py#L33), but it doesn't work well in under parallelized int systems where devices may appear later in boot.

Presumably this device checking was done as a safety pre-flight check for users which provide invalid fstab entries, to prevent users from creating fstab entries that would cause the system to not boot.

A workaround [has been proposed](https://github.com/canonical/cloud-init/pull/4673), and is blocked currently due to CLA/legal reasons. This workaround simply adds a timeout for devices to appear. While this may work around the issue temporarily, the solution is non-deterministic and inherently broken.

Cloud-init should handle a more dynamic early userspace environment gracefully.

## Cannot handle multi-device mounts

On some multi-device filesystems, a single device may exist in the first column of an fstab entry, with other devices represented as options (btrfs). When a single device is sufficient (mirroring, raid), and that device is available but not the device in the fstab field, cloud-init's behavior is incorrect since it may prevent such a line from being added.

This is really the same issue as the last section, but a different manifestation of the issue.