Allow further customization of Lima’s boot workflow

### Description

Lima currently tries to have sane defaults per every OS it supports when installing system dependencies (such as `iptables`, `fuse`, `sshfs`, etc.). This works great most of the time, but sometimes, further customization could be useful. Some examples are when adding support for a new OS, or installing customized/patched versions of those system dependencies, or even adding a custom package repository (yum/apt/etc.) before trying to install packages.

Additionally, customizing the dependency installation workflow could also enable advanced users to remove the requirement of internet access for downloading these dependencies (for example, if a user set up a local yum repository and then installs their system dependencies from that, rather than the default repositories).

Another nice to have feature is allowing Lima users to customize cloud init’s `cloud-init-local.service` behavior via `bootCmds`, which run very early in the boot process ([more info here](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#run-commands-on-first-boot)). Users can use this feature to disable unnecessary services via `systemctl` (or other means, depending on the OS), or run other arbitrary commands for other reasons.

In order to support all of these use cases, I propose adding a few new features to Lima’s config:

1. Allow users to add cloud init `bootCmds` directly in their Lima configs
1. This is a relatively straightforward change and would utilize the existing templating for CIDATA
2. Allow users to supply a new type of provisioning script of mode “dependency”
1. These dependency scripts would allow users to bypass the default logic in [30-install-package.sh](https://github.com/lima-vm/lima/blob/master/pkg/cidata/cidata.TEMPLATE.d/boot/30-install-packages.sh) and replace it with their own logic. Alternatively, the scripts could be made to run in addition to the default logic (with another new flag added to suppress the default logic)
3. Allow users to supply 1 or n “extra” archives that get added into CIDATA
1. This allows users to supply their own local packages or package repositories for use with a custom “dependency” script (since such a script would run before sshfs mounts are available)

If there is interest in these features, I plan on following up with several PRs to add the features mentioned in this issue. I can also split this issue into more granular issues, if that’s better.