Follow-up to #14491; if a volume is specified as `source: custom/c1`,
then a rename of `c1`->`c2` should leave the device with `source:
custom/c2`.

Includes commits from #14491 

This PR enables attaching a virtual machine's root storage volume to
another virtual machine via a disk device:
```
# vm2 yaml
...
devices:
  v1-root:
    type: disk
    pool: default
    source: virtual-machine/vm1
```

This has some constraints because simultaneous access to storage volumes
with content-type `block` is unsafe:
- `vm1`'s root volume can be attached to exactly one other instance if
`vm1` has `security.protection.start: true`
- `vm1`'s root volume can be attached to any number of other instances
if the storage volume `virtual-machine/vm1` has `security.shared: true`

`security.protection.start` is recommended for interactive use; e.g. a
user temporarily needs to access a bricked machine's root volume to fix
it or recover data. `security.shared` can be used if more than one
running instance must have access to the block volume.

## TODO
- [x] Docs
- [x] [lxd-ci](https://github.com/canonical/lxd-ci/) tests to validate
attachments to running VMs.
[Done](canonical/lxd-ci#366)
- [x] Bootorder bug (see comment) - current workaround is to hotplug
disk devices to avoid UUID/LABEL collisions at boot time.

I'm torn between the `volumeType/volumeName` and `sourcetype` syntaxes
for specifying other types of storage volumes in disk devices. A few
factors here, some I knew when I wrote my spec, but a few I didn't:
- By using `volumeType/volumeName`, we introduced novel syntax that the
server doesn't use anywhere else, and doesn't fit nicely with the
principle of "one value per map key" (see #14491).
- This syntax is already overloaded in the client to mean both
`volumeType/volumeName` and `poolName/volumeName` (see [`lxc storage
volume
copy`](https://canonical-microcloud.readthedocs-hosted.com/en/latest/lxd/reference/manpages/lxc/storage/volume/copy/#lxc-storage-volume-copy-md))
- The `storage.backups_volume` and `storage.image_volume` [server
configuration
keys](https://canonical-microcloud.readthedocs-hosted.com/en/latest/lxd/server/#miscellaneous-options)
also use `poolName/volumeName`

The current syntax for specifying volumes as disk devices is:
```
devices:
  cosmic-dust-analyzer-data:
	pool: default
	source: custom/cosmic-dust-analyzer-data
	type: disk
```

This PR uses this style instead:
```
devices:
  cosmic-dust-analyzer-data:
	pool: default
	source: cosmic-dust-analyzer-data
        sourcetype: custom
	type: disk
```

`sourcetype` is `custom` by default so it can be omitted for custom
volumes.

This is largely a revert of #14491. The functionality provided by the
reverted commits is implemented in the last commit here.

Rather than using a common `MountVolume` which changes its behavior
based on volume type, the disk device driver should choose the function
to call based on the volume type provided by the user in the
`source-type` field.