Improve support for fsencode, fsdecode, and path object detection, and allow rm_watch to take a path

[zbentley]

Four changes in this PR:

1. Allow rm_watch to take a PathLike or a descriptor number. add_watch now tracks created watches internally, and rm_watch uses and updates that tracker. close() clears the tracker out, which will help with the rare (but pertinent for me) case in which many hundreds of paths have been watched, taking up memory (and not being garbage collected right away since I use the raw inotify fd in asyncio, keeping the object around in a global deliberately-leaked pool even after it's closed; the other PR I submitted will help provide ways around that).
2. On older pythons, use the fsencode and fsdecode functionality in backports.os, which handles really nasty filesystem names better than the current implementations. backports.os is pure python, has no transitives, and only implements those two functions, so it's not pulling in a bunch of extra stuff.
3. Be a bit more pedantic about detecting PathLikes. Rather than probing parts, this code probes for os.PathLike and pathlib.Path directly. This helps deal with custom/weird path objects that may exist in the future. Hey, I said it was pedantic :)
4. Update a docstring to clarify the presence of long support on Python 2.

Open questions:

1. Should I probe for pathlib2.Path as well? It's the most popular pathlib backport (measured by stars/grep). Not proposing adding pathlib2 to install_requires, but I could try-import it and add it to the isinstance check.

[chrisjbillington]

Hi @zbentley,

I think it's out of scope for this project to track watches itself and accept filepaths or Paths for rm_watch - I want the interface to be very close to the underlying inotify interface.

In the latest release 2.0.0, I've dropped support for Python < 3.6 via the compatibility switches inotify-simple previously had, since Python 3.8 and earlier are end of life. Are any of the remaining fsencode/decode issues still relevant to newer Pythons?