tracker-miner-fs: Optimize mass-handling of delete operations

In the case that a very large directory (for most effect, non recursive) containing many indexed elements is deleted while tracker-miner-fs-3 does not run and the change found during next startup, the processing order of the startup checks will be from the indexed root folders (e.g. XDG folders) towards the deepest files.

This order is somewhat suboptimal for the existing checks attempting to detect and coalesce recursive deletes, meant to handle the case of detecting mass deletes found through directory monitors, which we detect in the opposite order (from deepmost files to the upmost folder). In abundance of DELETE events found during startup, this check falls into inadvertently quadratic behavior as no event gets coalesced.

Improve performance of the optimization itself, by:

• Ensuring it only applies to folders
• Avoiding the optimization entirely on a too large queue.

In the worst case, delete events will not be coalesced and handled one by one from the event queue. Although even on that case, the upmost folder will be processed first and delete all items at once, making the rest of the events almost free. Most importantly this avoids the quadratic behavior, resulting in less CPU and time spent on the operation, and it does not block the main thread main loop, which keeps "tracker3 status" fully responsive.

Closes: #263 (closed)