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.

Inizia tracciando la gestione di macOS FSEvents e il modo in cui ITEM_RENAMED, ITEM_CREATED e ITEM_REMOVED vengono attualmente interpretati. Riproduci i tre casi di spostamento descritti nell’issue, quindi definisci il completamento come la distinzione tra gli spostamenti verso l’interno, verso l’esterno e all’interno dell’ambito monitorato, senza affidarti soltanto a un controllo dell’esistenza nel file system.