[Windows] Remove deregistered sockets from the WSAPoll set before polling

[jakepetroules]

Motivation:

The WSAPoll selector did not remove a deregistered socket from pollFDs right away. It saved the array index in deregisteredFDs, and compacted the array later, after it delivered events. This caused three problems.

1. A closed handle could be polled. The compaction only ran when the poll returned events. If a socket was deregistered and the next poll timed out, its entry stayed in the array. NIO closes a socket right after it deregisters it, so the next WSAPoll received a closed handle. WSAPoll then reports POLLNVAL, and the selector treats that as fatal in preconditionFailure("Invalid fd supplied."). #3685 made deregistration really happen during shutdown, so this became easier to hit.

2. A live registration could be deleted. The compaction also removed the registration from registrations, but Selector.deregister had already done that. Windows reuses socket handles often. If the same handle was registered again in the meantime, this deleted the new registration, and the new channel stopped receiving events.

3. One handle could have two entries. The old entry was still in the array, and register0 could append a second entry for the same handle. One readiness event was then delivered twice. The second delivery finds no data, which trips assert(readResult == .some) in BaseSocketChannel. I have seen this fail from time to time on Windows.

Modifications:

• deregister0 now clears the handle in the entry immediately. A later register0 for the same handle cannot be mixed up with it.
• whenReady0 compacts pollFDs at the start, before it polls. This covers every path out of the previous call, so a closed handle is never given to WSAPoll.
• The compaction no longer touches registrations. Selector.deregister owns that.
• deregisteredFDs becomes a Bool, which is cheaper than a Set<Int>.
• Two assertions were added: the wakeup socket stays at pollFDs[0], and a socket is not registered twice.

POLLNVAL still traps, on purpose. Like EBADF, it means NIO lost track of a descriptor. Windows reuses handles, so using such a handle could send I/O to the wrong channel. After this change the deregister-then-close path no longer causes POLLNVAL, so a trap there now points to a real bug.

These files are Windows-only. Other platforms are not affected.

Result:

Tested on a Windows ARM64 machine (Swift 6.3.2). This commit builds on its own. It was also tested inside a larger branch, where a full swift test passes (2360 tests, 0 failures) in several runs.

About the assert(readResult == .some) failure: this removes one cause, but maybe not the only one. A listening socket can report POLLRDNORM, and accept can then return WSAEWOULDBLOCK, which looks the same. So please read this PR as a fix for the three problems above, not as a proven fix for that failure.