Default mounts need to be more streamlined

Nobody has claimed this yet.

**What are you trying to do?**
Since Multipass 1.14, sshfs mounts have become much more restrictive in what they can achieve with their default setting due to permissions being denied for all but the ids defined in the gid/uid mappings. A mapping of `default:1000` is added for group and user ids, but for many users that is not enough and a mapping of `0:0` is often required.

This makes workflows more tedious as mappings must be explicitly defined. This is further exacerbated by the limitation of the `launch` command where a mount and mappings cannot be specified in the same command.

**What's your proposed solution?**
I anticipate this becoming a reoccurring issue for Multipass where users complain about `permission denied` as the behaviour is unexpected. There are several things we can do to try to mitigate this problem:

1. Documentation

More documentation could be added in an effort to warn the user about the limitations of sshfs and/or their security vulnerabilities. This could be in the form of extended explanations on [multipass.run/docs]() or editing done to the help text of the `mount` command.

2. Changing the default mount type on launch

The restrictive nature of mappings and permissions is limited to only sshfs mount. We could regain the previous behaviour of sshfs mounts by instead defaulting to native mounts on launch. This has been talked about in the past, but this is an opportunity to bring it up for discussion again.

3. Modify the `launch` command to allow for mappings

A possibility, but would add complexity to the already very busy `launch` command. Special consideration would have to be given to make sure that commands remain valid with the additional options.

**Additional context**
Original github issue describing the issue with mappings and sshfs mounts: https://github.com/canonical/multipass/issues/3179

Start by reviewing the original mapping issue 3179 and the launch and mount command behavior described here, including the proposed documentation and help-text changes. This issue is not scoped to one solution; done would require choosing and implementing an agreed mitigation for restrictive default mounts and validating the resulting command behavior.

Written by the indexing model from the issue text.