Signal the watch key when its watched directory is deleted

[tanvir-ux]

Fixes #72.

When a directory registered with a Jimfs WatchService is deleted, the polling task fails to snapshot it and cancels the key, but it never queues the key. A thread blocked in take() therefore keeps waiting forever and never learns that the key became invalid.

The JDK services handle this case by cancelling and then signalling the key (sun.nio.fs.PollingWatchService does cancel(); signal(); when the directory is no longer accessible, and LinuxWatchService does the same on IN_IGNORED). On the default file system on Linux, poll() returns the key after the directory is deleted, with isValid() == false and reset() == false.

This change makes Jimfs do the same thing by calling key.signal() right after key.cancel() in the polling task's IOException branch. close() still cancels keys without queueing them, so its behavior is unchanged.

Testing:

• Added PollingWatchServiceTest.testDeletingWatchedDirectoryCancelsAndSignalsKey. It registers a directory, deletes it, and expects poll(1, SECONDS) to return the same key, now invalid.
  • Before the fix it fails: expected specific instance: ...Key@... but was: null.
  • After the fix, PollingWatchServiceTest passes 9/9.
• Full jimfs module: mvn test passes 5906 tests (1 skipped), JDK 21.