Don't trigger DocumentManager.pathDeleted on document objects too soon

This effectively fixes issue #9400 byNot triggering the `DocumentManager.pathDeleted` event on document objects when `ProjectManager` calls `DocumentManager.notifyPathDeleted()` and the path has a `Document` object.

For `Document` objects , `FileSyncManager.syncOpenDocuements()` will call  `DocumentManager.notifyFileDeleted` for each `Document` object whose view needs to be destroyed and its file removed from the working set.

Prior versions of `DocumentManager.notifyFileDeleted` called `DocumentManager.closeFullEditor()` which called `removeFromWorkingSet()`; 

Now this is done in `Pane.handleFileDeleted` when the `DocumentManager.pathDeleted` event is handled.   The `DocumentManager.notifyPathDeleted` case which triggered `DocumentManager.pathDeleted` was handled by the Editor to close down Image Views.

This is safe as no other code uses this event. There are a few extensions using this event but the impact should be positive since we don't want to trigger the event until `FileSyncManager` notifies `DocumentManager` on actual deletions. For non-document objects (images) it should be OK to dispatch the event when we get it. This will be the only time we get a notification for non-document objects anyway so we *have* to do dispatch the event during `DocumentObject.notifyPathDeleted` or it won't be removed from the working set and its view closed.

Recommended Test Scenarios:

- [ ] Open a file to the working set don't change it and delete it from the file tree
- [ ] Open a file to the working set, change it and delete it from the file tree
- [ ] Open a file to the working set, don't change it and delete it from Finder/Explorer
- [ ] Open a file but don't add it to the working set and delete it from the file tree
- [ ] Open a file but don't add it to the working set and delete it from Finder/Explorer
- [ ] Open an image to the working set and delete it from the file tree
- [ ] Open an image to the working set and delete it from Finder/Explorer
- [ ] Open an image but don't add it to the working set and delete it from the file tree
- [ ] Open an image but don't add it to the working set and delete it from Finder/Explorer
@JeffryBooher 
> what we should do, however, is change the logic so that it only fires the pathDeleted event from notifyPathDeleted for paths not in any working set (temporary views) since the FileSyncManager will call notifyFIleDeleted and we effectively trigger the pathDeleted event twice. This is a benign case but should be easy to impl and done to avoid confusion.

Note that `getOpenDocumentForPath()` and `getAllOpenDocuments()` (which FileSyncManager uses) cover _anything_ with an Editor, even if it's just a temporary view or an inline editor with no full editor open.  So we don't really want/need to distinguish 'in working set' from not -- we just need to distinguish 'Document exists' from not.

When you say "it only fires" above, do you mean "`notifyPathDeleted()` only fires" or "`notifyFileDeleted()` only fires"?
* If `notifyPathDeleted()`, I think it should be: it only fires `"pathDeleted"` for items that _don't_ have a Document (which is what this PR does).
* If `notifyFileDeleted()`, I think it should be: it only fires `"pathDeleted"` for items that _do_ have a Document (since for items that don't, it's redundant with the event already sent by `notifyPathDeleted()`... _But_ I think that's not needed: since `notifyFileDeleted()` is only called by FileSyncManager, it's only ever called for things that _do_ have a Document, so the case we'd want to filter out is never hit anyway.