Initial sketch of a Factory class for configuring Annotator

The motivation for this commit is as follows:

- Annotator is increasingly being used as a building block -- a
  component of a larger application, rather than in its default
  configuration.
- In this mode, configuring an "annotator application" is rather
  hit-and-miss. Existing dependencies between plugins are managed in a
  somewhat haphazard way, and indeed, all plugins are added *after*
  Annotator's main events are bound, which leads to race conditions when
  plugin initialisation is asynchronous.

This commit sketches out an Annotator instance factory named,
imaginatively, `Annotator.Factory`. This factory allows the
specification of a particular annotator application (an assemblage of
core components, plugins, and their attendant configuration) "offline,"
without binding any events to the DOM (or other documents).

Instances of the Annotator can then be retrieved from this preconfigured
Factory, each of which is entirely independent of the other. Each of
these instances can then be independently bound to particular elements
of the DOM.
Allow store and plugin constructors to receive arguments

Some store implementations and plugins will want to accept arguments in
their constructors. This commit allows the `setStore` and `addPlugin`
methods of the factory to accept additional arguments which are in turn
passed on to the relevant constructors when building an Annotator
instance.
Replace Registry with Factory and rejig Annotator boot

This commit replaces the Registry object (itself a kind of factory
class) with Annotator.Factory, a factory object that is hopefully
clearer in its naming, intent, and usage.

We also rejig the Annotator constructor, so it is possible to construct
an unbound Annotator object (as the Factory does).
Minor whitespace fixes in Auth plugin
Fix initialisation of plugins in Factory mode

Some plugins assume that `annotator.element` is set when `pluginInit` is
called. This commit moves the binding of Annotator's delegated events to
the attach method, fixing the behaviour of the adder, viewer, etc.
Simplify module loading and layout

This commit removes some of the magic that we were using to dynamically
rewrite plugin module names within this package (so that you could, for
example, require('annotator-plugin-permissions') within another plugin).

I don't see that we really need the features provided by this extra
code, so I've gone ahead and removed it :)

As of this commit, we have the following:

- building pkg/annotator.js (or -full, or -bookmarklet) will result in a
  packaged file which can be required as 'annotator', or which will
  export the Annotator name to a global window object, if it exists.
- building pkg/annotator.<pluginname>.js will result in a packaged file
  which requires 'annotator' but does not include it inline.
Begin to decouple plugins from the Annotator namespace

Part of the complexity removed in the previous commit was the result of
needing the ability to build individual plugin files which added
themselves to the Annotator namespace.

This commit starts to unpick some of this complexity, by allowing
plugins to register themselves in a singleton "plugin pool" by name,
rather than somewhat hackily adding themselves to a global shared
object. The result is broadly similar, although this feels cleaner and
more explicit.

One implication is that plugins *must* now be loaded after Annotator
core, although I don't see that this will cause many problems.

As of this commit, inter-plugin interactions are still broken.