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.

Empieza rastreando el manejo de macOS FSEvents y cómo se interpretan actualmente ITEM_RENAMED, ITEM_CREATED y ITEM_REMOVED. Reproduce los tres casos de movimiento descritos en el issue y, después, define la finalización como la capacidad de distinguir los movimientos hacia dentro, hacia fuera y dentro del ámbito observado sin depender únicamente de una comprobación de la existencia en el sistema de archivos.