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.

まず macOS FSEvents の処理を追跡し、ITEM_RENAMED、ITEM_CREATED、ITEM_REMOVED が現在どのように解釈されているかを確認します。次に、issue で説明されている 3 つの移動ケースを再現し、ファイルシステムの存在チェックだけに頼らず、監視対象範囲への移動、監視対象範囲外への移動、監視対象範囲内での移動を区別できることを完了条件として定義します。