remove_watch functionality

[Elias481]

Few points regarding remove_watch functionality.

1. remove_watch should propagate superficial argument to remove_watch_with_id (but I see Propagate superficial parameter to remove_watch_with_id #57 is already in place for that)

• for this this the Tree-Handling would need probably a fix (use superficial only for currently unhandeled but probably wanted DELETE event Fix constant in adapter to match with DELETE events #58 / Recursive watching fails on directory deletion #51 but not for MOVED_FROM as this does not unregister the watch from inotify see also Moving a previously removed folder crashing #46 for a possible result...)

2. I would like a public method to remove a wd only from underlying inotify (inotify.calls.inotify_rm_watch) to have possibility to remove the watch from one thread and watching thread is propagating the change which is does not using public remove_watch as it suppress the event if diretory name cannot be looked up) - possibly just a parameter (why not reuse superficial so True = only tracking information, False = tracking information + watch, None = watch only...)
3. method remove_watch_with_id should not be public (without _) in current form as the self.__watches is not cleanup up using this method and there is no public method to only cleanup that - but best to make both existing methods removing both forward and reverse lookup entries for wd (and if superficial is False also remove the wd from underlying inotify)
4. think about handling IN_IGNORE events received (in this case the the wd was unregistered automatically by underlying inotify) - so IN_IGNORE could cause automatic remove_watch with superficial set to True (sure that could be left up to the user. but at least there should be working methods for this case, currently is neighter - one does not support superficial the other does not remove forward entry from map..) - anyway if this would be implemented this could break the

Btw. in _BaseTree event_gen is another bug... The IN_MOVED_TO is handled twice so it will log a warning in that case...