fix: detect a disk's VM change with the correct schema key

[nagaboinaramgopal]

Description

The disk update detects a change of the attached VM to trigger a detach and re-attach, but it checked d.HasChange("virtual_machine") and the schema key is virtual_machine_id. HasChange on a key that does not exist is always false, so changing virtual_machine_id never ran the detach branch: the disk stayed attached to the old VM, and because attach is skipped when the volume is already attached, it was never moved to the new VM. Fixed to check virtual_machine_id.

Making that branch reachable exposed a second bug in the detach fallback. When a plain detach fails, the fallback stops the VM to force the detach and then restarts it, using the current virtual_machine_id. During a VM change that value is the new VM, but the disk is still on the old one, so the fallback would stop the wrong VM. It now uses the old value (via GetChange) when virtual_machine_id changed.

Testing

Two unit tests, no live CloudStack:

go test ./cloudstack/ -run TestDiskUpdate

TestDiskUpdateDetachesWhenVirtualMachineChanges asserts a virtual_machine_id change reaches the detach path; before the fix it falls through to attach. TestDiskUpdateDetachFallbackStopsSourceVM uses a stub server and asserts that when the plain detach fails, the fallback stops the source VM (the old id), not the destination.