Regularly scrub query history view

[edoardopirovano]

This PR triggers a scrubbing of the history view after we've deleted old queries. I also considered (and, in fact, implemented to try it out) tracking what queries we have deleted the directories of, and only removing those from the query history view. This seems reasonable, since it avoids a few filesystem checks. However, those checks are pretty cheap, and that solution runs into issues if another workspace deletes a query in which case it will stay in our view forever. With my chosen approach, it will at least get deleted within 2-3 hours on all other workspaces when they run a scrub (and immediately on the one that performed the deletion).

A further extension we talked about would be to this would be to wrap all methods that try to access the query directory, and if those find that the file they are looking for no longer exists then trigger this scrubbing method to remove invalid entries from the history and give a friendly message to the user rather than the current file not found error. This would improve the UX when users have multiple workspaces open and try to access a query that has been deleted in another one. That change is quite involved, though, because there's so many different methods that use the query directory, and I can't think of a nice way to catch all these errors at a higher up level either. Thus, I'm not sure if we actually want to do this, since it introduces a fair bit of tech debt for a small UX improvement in a corner case.

Checklist

• CHANGELOG.md has been updated to incorporate all user visible changes made by this pull request.
• Issues have been created for any UI or other user-facing changes made by this pull request.
• [Maintainers only] If this pull request makes user-facing changes that require documentation changes, open a corresponding docs pull request in the github/codeql repo and add the ready-for-doc-review label there.

[aeisenberg]

This means there is a window of < 2 hours when a query may exist in an open workspace, but have been deleted on disk (only if there are multiple workspaces open at once). I think this is a minor issue and unlikely to happen.

[aeisenberg]

Minor: No need to check if item.completedQuery is truthy if your are using .? later on.

Suggested change

	if (item.t == 'local' && item.completedQuery && !(await fs.pathExists(item.completedQuery?.query.querySaveDir))) {
	if (item.t == 'local' && !(await fs.pathExists(item.completedQuery?.query.querySaveDir))) {

[edoardopirovano]

Unfortunately, I don't think that can be omitted. Without it, the compiler will complain that item.completedQuery?.query.querySaveDir is not a valid argument to fs.pathExists because it may be undefined.