This is an alternative approach to fix the issue described in
https://phabricator.kde.org/D15899

The approach used here is generic and does not require any users
of the API to know about the potential pitfalls, it actually
decreases coupling a bit!

The old approach to cleanup the list jobs only worked when we
called AbstractFileManagerPluginPrivate::removeFolder, but that
wouldn't work when a folder item gets deleted directly - e.g.
from the CMakeManager or any other code. Now, we listen to
the model signal when a row is about to be removed and cleanup
the item pointers in the list job. While doing so, we must make
take into account that the pointer may already be partially destroyed,
since only the ProjectBaseItem dtor will call takeRow, at which point
the overriden methods in ProjectFolderItem e.g. won't be available
anymore.

Additionally, it turned out that the fallback for a similar handler
of partially destroyed classes in
AbstractFileManagerPluginPrivate::jobFinished only removed the job
from a copied list, since it was using foreach, and didn't even take
the list by reference...

Finally, the test is expanded to reliably trigger the crashy behavior
explained in the review request on phabricator.

BUG: 260741