goldfish_rtc device incorrectly migrates tick offset as an offset from QEMU_CLOCK_VIRTUAL

The pl031 RTC used to migrate its tick offset by recalculating it as an offset from QEMU_CLOCK_VIRTUAL. This seemed like a clever idea but it turns out to be a bug -- if you save the VM and then restore it, the guest RTC on restore is out of sync with the host RTC, because the VM clock stands still across a save-and-restore. For the pl031 we fixed this in commit 032cfe6a, which is a combination of "just migrate tick_offset" and "back-compat machinery to handle migration compat with older QEMU versions that used the offset-from-virtual-clock".

Unfortunately it looks like the goldfish_rtc device copied this incorrect offset-from-QEMU_CLOCK_VIRTUAL handling, so it needs a similar fix. If we don't care about migration compat on that device (which I think may be the case) we can skip the complicated compat handling and just bump the version and migrate the simple tick_offset.

Looks like this affects m68k "virt", mips "loongson3-virt", openrisc "virt" and riscv "virt" boards.