Use an internal index to more accurately track renames on macOS

When a file is moved and we're using the native FSEvents API on macOS, it issues native events with flag ITEM_RENAMED set, but not flags ITEM_CREATED or ITEM_REMOVED. Typical cases include:

1. Moving a file within the watch scope. In this case, there are two native events: one for the source (logically: delete), and one for the destination (logically: create).
2. Moving a file into the watch scope. In this case, there is one native event, for the destination (logically: create).
3. Moving a file out of the watch scope. In this case, there is one native event, for the source (logically: delete).

Because flags ITEM_CREATED and ITEM_REMOVED aren't set, the native events in cases 2 and 3 are indistinguishable. Currently, this is solved by asking the file system if the file exists: if it does, we assume it's case 2; if it doesn't, we assume it's case 3. However, this can be inaccurate (because things can have happened to the file between the native event was issued and asking the file system). A more accurate approach could be to maintain our own index.

Beginne damit, die Verarbeitung von macOS FSEvents nachzuverfolgen und zu untersuchen, wie ITEM_RENAMED, ITEM_CREATED und ITEM_REMOVED derzeit interpretiert werden. Reproduziere die drei im Issue beschriebenen Verschiebefälle und definiere anschließend die Fertigstellung als die Unterscheidung von Verschiebungen in den, aus dem und innerhalb des Überwachungsbereichs, ohne sich ausschließlich auf eine Prüfung der Dateisystemexistenz zu stützen.