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.

Commencez par suivre le traitement de macOS FSEvents et la manière dont ITEM_RENAMED, ITEM_CREATED et ITEM_REMOVED sont actuellement interprétés. Reproduisez les trois cas de déplacement décrits dans l’issue, puis définissez l’achèvement comme la distinction entre les déplacements vers l’intérieur, vers l’extérieur et à l’intérieur du périmètre surveillé, sans vous appuyer uniquement sur une vérification de l’existence dans le système de fichiers.