apple2gs: fix inconsistent clocks

[arekkusu42]

This commit fixes apple2gs to stop using two slightly different 1 MHz clocks:

• 1022727 used in update_speed() and IWM()
• 1021800 used when toggling the ZipGS, and expected by the 262-line video @ 60Hz

Making the clocks consistent fixes the out-of-sync flickering/slowing rolling drift visible in some beam-racing demos, such as French Touch CC65C02 or deater's double (first part, the second part syncs to C019 instead) or fancy lores.

More complicated intra-scanline beam racing (as used in the first two of those demos) still doesn't work (the 16 MHz screen timing has no HBL and 14 MHz cliprects are scaled weird and also not honored) but this is enough to make simple whole-scanline timing stable.

This change undoes part of 623e248 which changed the IWM() Q3 clock. That change made it consistent with the old A2GS_1M; now it becomes consistent with the rest of the apple2 1021800 clocks.

Due to the ongoing disk corruption #14474, I ran a bunch of before/after testing on the IWM, with and without the ZipGS enabled:

                                                        Before 2.8 7 16 After 2.8 7 16
* Apple IIgs Diagnostic v3.1: Disk Port Test, 100 iterations     √ √ √          √ √ √
* Disk Muncher 2.0: copy DOS3.3 35-track disk to blank, boot it  √ √ √          √ √ √
* Apple II System Utilities 3.2: FastCopy & Compare ProDOS disk  √ √ √          √ √ √
* GSOS 6.0.4 Finder: initialize ProDOS blank, drag-copy disk     √ √ √          √ √ √
* XPS Diagnostic IIe 1.0.5: E) CPU G) DISK L) MEDIA              1 2 2          1 1 1

1: XPS shows the same errors before and after:
G) DISK SYSTEM shows SEEK errors
L) MEDIA VERIFY shows errors reading the last track
These errors don't occur in apple2ee with diskiing.  I don't have functional floppy disks to verify this against my IIgs hardware...

2: XPS shows disk corruption with the ZipGS:
G) READ errors in addition to SEEK
L) MEDIA VERIFY shows error with tracks 0, 33 and 34 (and then the disk was corrupt)
(corruption was intermittent but repeatable, running E) G) L) on fresh copies of the XPS disk.)

Note that all of the typical user-facing tasks appear to succeed before this PR, including the long-running Disk Port Test! So whatever the timing problem is that causes corruption in XPS, it is subtle and intermittent. Making the IWM Q3 clock consistent with the ZipGS 1 MHz temporary delay clock appears to fix (or at least, avoid) the problem.