Add the ability to trigger “resurrection” logic…

[savetheclocktower]

…to make it easier for other tools to tell us when one of our isDeleted() buffers has been resurrected.

(This PR will stay in draft until #15 lands.)

This PR implements what is described in #16. Since we don't have the tools to detect on our own exactly when a deleted file becomes un-deleted, we will instead expose an imperative method called resurrect that will do all the things we would do if we could simply attach an onDidUndelete handler somewhere.

Pulsar already imports watchPath (our recursive file-watching library) into src/project.js. We can set up a listener on each project root whose logic looks a bit like this:

• Detect created file event
• Look for an open buffer whose path corresponds to that created file
• If there is one, call TextBuffer::resurrect()

The new logic in specs tests two different deleted-and-resurrected scenarios: one where the buffer has uncommitted changes and another where it doesn't. The latter is the simpler case, of course. In the former scenario, we can detect the conflict when the buffer reload fails to work as expected and transition to a “conflicted” state.

I've also added a couple of methods to make our lives easier on the consumer side. We had onDidConflict and onDidDelete, but those imply that transitioning into a “conflicted” or “deleted” status is a one-way operation. We already had onDidChangeModified, so I added onDidChangeConflicted and onDidChangeDeleted in the same style.

The tabs package will prefer these new callback methods if they exist, but will fall back to onDidConflict and onDidDelete if they have to.