Activation commands

## Remaining Work
* [ ] Fix failing specs due to jQuery `trigger` being called for commands instead of native event dispatch.

## Description
This PR properly integrates the new global command registry (`atom.commands`) with package activation events. It does the following:

* Switches the syntax of `atom.activationEvents` to `atom.activationCommands`. This hash has mandatory selectors mapping to strings or arrays of strings as follows:
```coffee
  activationCommands: {
    ".workspace": [
      "project-find:show",
      "project-find:toggle",
      "project-find:show-in-current-directory",
      # ...
    ]
  }
```
* Uses `atom.commands` instead of `$::command` to listen for package activation. This means we won't need to use a deprecated API to support this behavior when we deprecate `atom.workspaceView` and `$::command`.
* Ensures that commands registered with `atom.commands` are invoked only once even when the activation command is replayed after activating the package.

This is delicate work but I'm pretty sure it preserves existing behavior. Specs pass and I tried a handful of baked-in packages without issues. The last remaining issue is to deal with specs that call `trigger` to invoke commands, which isn't picked up by our native handlers. I'd like to find a way to enhance jQuery's `trigger` to invoke real DOM events. One nice thing: Because the command registry uses the [capture phase](https://developer.mozilla.org/en-US/docs/Web/API/EventTarget.addEventListener) of events, we don't need to disable the jQuery event listeners anymore to prevent them from being invoked twice. We stop propagation of the activation command and reinvoke it after activating the package. It's this second invocation that ends up calling listeners registered via jQuery.
Yes, but not yet. I want to get the full alternative approach in place before bothering people to use `atom.commands`.