WIP - Refactor thunar file monitoring

• Remove ThunarFileMonitor. Instead, directly subscribe to "changed"/"destroy" signals of relevant ThunarFiles for the first.
• Provide "files-changed" signal on ThunarFolder and make use of it where it makes sense.
• Introduce rate-limiting for the following signals:
  • ThunarFile "changed"
  • ThunarFolder "files-changed"
  • ThunarFolder "files-added" already done by @Elessar1802
  • ThunarFolder "files-removed" already done by @Elessar1802
• Instead of directly delaying, first emit the signals, and then use the delay to wait at least DELAY_TIME until the next emit
  • Like that, the delay can be increased without loosing responsiveness
  • File-selection than should continue to work in most cases (Meh, select after rename and list-view still have issues)
• Rate-limiting for file-selection - see here: (Fix trash freeze)

---

This probably should go to a separate MR:

• further improve file-selection mechanics
  • It might make sense to store the "files_to_select" as well inside ThunarFolder, apply the same rate-limiting and provide a signal "selection-changed" on it ... to be checked.
  • Store them as gFiles, before the files are actually available ?
  • When files-added is triggered, the stored files_to_select can be checked, and selection-changed can be signaled

---

This will be done in !369 (merged)

• Use GHashTable for files in ThunarFolder in order to prevent expensive iterations on the files list (see this comment)

This change is supposed to fix #1146 (closed), #892 (closed), #528, #259 (closed), #182 (closed), #114 (closed)

Hopefully it as well can fix #1077 (closed), #854 (closed) and some others … to be checked after merge

@Elessar1802, @zaps166: You think it makes sense like that ? Imo should be much more straight forward and should make rate-limiting inside all other subclasses/views obsolete, since "row-changed" and others usually are triggered by one of the signals above. Any suggestions / critics / comments are welcome!