Events: allow promise return values from event callbacks

This commit adds events.coffee, which exports Events, an extension of
BackboneEvents to include a `triggerThen` method which returns a
promise, fulfilled either when all the event callbacks have run, or, if
some of them return promises, that all the returned promises are
fulfilled as well.

This will make it possible to implement such things as
`beforeAnnotationDeleted` handlers that prevent the deletion, and, more
immediately, an Editor which can use `beforeAnnotationCreated` and
`beforeAnnotationUpdated` in order to present itself for editing.
Minor tweak to dev.html
Improve interface of AnnotationRegistry

- Observe the promise returned by triggering
  `beforeAnnotation{Created,Updated,Deleted}` events and only proceed to
  make the appropriate store calls if the promise is fulfilled.
- Remove the nasty event proxying, and simply trigger events on the core
  instance directly.
Add show{Edit,Delete}Button options to Viewer

These options can be toggled orthogonally to one another to change the
display of the viewer.
Make Editor into an independent plugin

This moves the last piece of user interface out of Annotator core and
into its own plugin. This was by far the most involved piece for two
main reasons:

1) Unlike Adder, Viewer, and Highlights, the Editor has the ability to
   interrupt the annotation lifecycle. The Adder requests an annotation
   be created, or the Viewer requests an annotation be updated, but the
   Editor has the ability to cancel that request.

   This problem has been solved by making the `before*` lifecycle events
   detect promises returned by their callback functions (see e90efe2),
   and abort the intended action if any of these promises are rejected.
   The Editor plugin hooks into `beforeAnnotation{Created,Updated}`, and
   displays the editor. If the editing is cancelled, the promise is
   rejected and the process aborts.

2) Like the Viewer, the Editor needs to know where to position itself.
   Unlike the viewer, its appearance is not (necessarily) triggered by a
   user mouse event from which we can extract the right position.

   This problem is solved by making both the Adder and the Viewer store
   the user's position in the `interactionPoint` property on Annotator
   core. If this property exists, the Editor will use it to position
   itself.

   This solution means that the Editor can be used solely with the Adder
   (without the Viewer) or indeed that it can be used with an entirely
   different type of adder plugin that sets `interactionPoint` in a
   different way.