Rework GithubPackage model and promise management

[smashwilson]

I'm revisiting the way that GithubPackage manages the per-project models it tracks (Repository, Project path, and ResolutionProgress) to reduce some of the Promise soup we've got going on and ensure that the models are updated consistently.

While I'm in there, I'm attempting to streamline the way that models are initialized when the package is activated in different situations:

• First launch of a single project without saved state (the problem observed in Opening a git project in Atom for the first time doesn't detect git info in package.  #623);
• Launch of a single project with saved state to deserialize;
• Package activation when projects are already present in the workspace.

Remaining

• Implement WorkdirContext
• Implement WorkdirContextPool
• Accept and propagate saved ResolutionProgress state
• Update observers to accept a Repository synchronously
• Discover a containing git working directories from a file path instead of a Project path
• Integrate WorkdirContextPool into GithubPackage, replacing the modelsBy... maps
• Ensure we have test coverage for active context management in GithubPackage including:
  • When activating
  • When the project paths change
  • When the active item changes
• Use updated protocol for PaneItems
• Wire it up for performance instrumentation

[smashwilson]

This replaces the .getInitialModelsPromise() and friends, but it still smells to me.

The EventHandler from #617 would be somewhat more natural, but the whole "construct a promise that will resolve the next time X occurs" pattern feels off. I'm wondering if what we really need is an EventHandler that emits events when X occurs, with an API on top of it to build Promises that resolve the next time an event is handled? Still thinking about that one.

[smashwilson]

When launching Atom from the command-line with a single project, the package is activated before projectPaths are populated. This was the root cause of the regression in #623: the updateActiveModels() calls in deserialize() and in didChangeProjectPaths() were happening too early and missing the project. Our test cases all set the project paths before activation, so they were passing correctly.

[smashwilson]

@ungb I've reproduced #656 and verified that it was fixed by the changes merged in from #654. Thanks for the report ✨