Allow updating Volume topology

### Proposal
Allow to update Volume CSI topology.

### Use-cases

I'm writing CSI plugin for LVM. I took https://github.com/metal-stack/csi-driver-lvm and replaced Kubernets with Nomad and it works.
Using LVM is not a typical use for CSI as it's not a network file system. Volume is available on a specific node only, and I'm setting a proper topology so nomad schedules allocation on a correct node. This works as expected.

The issue is when for some reason I have to move volume to another node. Why would I do that? Because of maintenance of the current node or simply when I want to replace the node.

The process would be like this:
1. Stop the job
2. Migrate the data
3. Update Volume topology
4. Start the job and allow nomad to schedule allocation on the new node.

This is not possible though because updating topology [is not allowed](https://github.com/hashicorp/nomad/blob/main/nomad/structs/csi.go#L807). I'm not sure why, though.

### Attempted Solutions

My current solution is:
1. Stop the job
2. Create a new volume
3. Migrate data.
4. Update Job with new volume
5. Delete old volume.

This is not a perfect as there is a risk of doing it in a wrong order and deleting a wrong volume :)

What are your thoughts on allowing updating topology?

Start in nomad/structs/csi.go around the topology update restriction at line 807, then trace how CSI volume updates are validated. Compare that behavior with the proposed stop, migrate, topology-update, and restart workflow; done means the project has a decided, safe way to support or reject topology changes.

Written by the indexing model from the issue text.