This PR introduces test helpers and new integration tests for watchers.

• Adds a new test module containing reusable utilities (e.g., testdir(), channel(), TestWatcher, Receiver, expected()) to streamline writing and maintaining file-system event tests. I think it is the main point of an interest
• Adds a collection of new tests covering creation, modification, renaming, deletion, hard-links, recursive directory creation and more - across multiple watcher backends (each backend has its own specific tests).
• Adds some watcher-agnostic tests for RecommendedWatcher
• There are no production code changes; almost all work is in test code and helpers. The only one is added fn poll_sender for the PollWatcher, but it has #[cfg(test)] either

The tests already have found bugs: #727, #729

Remark: surprisingly, poll watcher is the most flaky due to a slow file system - the file may still appear in an immediate readdir result. Because of that, I had to introduce a small helper I didn’t really want to: sleep_until.
PollWatcher tests follow the pattern watch -- do something -- wait for fs state -- detect changes -- check, which seems reliable enough.

@dfaust I think I've done it

The main point to check is test helpers in notify/src/test.rs, I tried to make it clear and simple, but I'm not sure.

The tests follow the pattern

• creates testdir() - it is required due to macos behaviour, where the TempDir has non-canonicalized path, but we trigger it canonicalized in events
• creates a TestWatcher + Receiver.
  • TestWatcher<W: Watcher> is a simple helper panicking on Err from watch calls
  • Receiver is a rx-part of the mpsc::channel and used to wait new events
• calls some wait_ method on Receiver:
  • wait_ordered - wait events in the same order as its provided
  • wait_unordered - wait events in the same order as its provided
  • wait_..._exact - as above, but panics if encountered an unexpected one

The main idea to compare events is test::expect module. It introduces

• ExpectedEvent - a helper, that can be used to PartialEq<Event>. It may be created in any way, like expected(path) matches any event with the specified path, expected(path).modify() matches an event with an equal paths and EventKind::Modify(_), expected(path).modify_content_any() matches path and Modify(Content(Any)) and so on
• event(path) / event([path1, path2]) - fn to create expected event from something path-like (&Path, PathBuf, [&Path] etc.)
• ExpectedState / trait ExpectedCollection are helpers to check a collection of ExpectedEvent.
  It may be ordered, may handle optional and multiple events and make well-read panic messages (The example from CI)