Add CommandRegistry::dispatch for tests
Don’t clear commands after specs

Commands are typically registered once at eval time. Clearing them
means that commands aren’t available except in the first spec.
Return whether a dispatched command matched a listener
Extract package-manager-specs from atom-specs
Dispatch activation commands with native DOM apis in specs
Restore commands after each spec

This commit adds the ability to get and restore snapshots of command
listeners. Whatever commands are installed before specs begin are
preserved, but commands added during specs are always cleared away.
Allow atom.commands to participate in activationEvents

* Activation events can be handled via atom.commands
* Pre-existing listeners registered via atom.commands are disabled when
  replaying events for the activated package.
Handle dispatching non-existent commands
Forward stop[Immediate]Propagation to original event in CommandRegistry

Previously, stopping propagation would work on the synthetic bubbling
phase of the command registry itself, but the original event would
continue to propagate which is counterintuitive.
Use the CommandRegistry to register activation event listeners

Commands registered with the command registry will always be handled
first, so as long as we disable any listeners in the registry that were
already invoked for the current command, we don’t need to disable jQuery
methods before replaying the command after activating the package.

This commit adds the ability to call .disableInvokedListeners on the
event passed to the command listeners. This returns a function which
can be called to reenable them.
Default selector to .workspace when subscribing to activation events
Support activationCommands field in package.json

This field mandates selectors in its structure and closely matches the
API of `atom.commands.add`. It will supplant `activationEvents` moving
forward.
Switch specs to use activationCommands instead of activationEvents

The activationEvents are converted to the same format as
activationCommands, and that property will be deprecated.
Process commands invoked with jQuery trigger in CommandRegistry

Especially in specs, trigger has been used to invoke events. jQuery does
not invoke native listeners in this situation, so we use ::on to listen
for them instead. If we didn’t handle the event with a native capture
handler, we’ll still support invoking via trigger.
Merge pull request #3611 from atom/ns-activation-commands

Activation commands