bookmarklet: jQuery 1.9 isn't a thing, apparently
Move backbone-* to dependencies

These are real run- and build-time dependencies, not dev dependencies.
Add packaging directories to .gitignore
Embed jQuery in the built annotator

Rather than depending on an externally loaded jQuery, this commit causes
Annotator to embed its own copy of jQuery within its own closure, using
this for DOM manipulations.

This has a number of advantages, and a number of disadvantages. The
advantages first:

- We don't have to sniff the current page or execution context to
  determine whether jQuery has been loaded and issue a somewhat obscure
  warning when it's not.
- We can depend on whatever version of jQuery we like, regardless of the
  state of the outside world. Up until now, we were relying primarily on
  the jQuery project's good approach to backwards compatibility, but
  even with their conservative deprecation schedule, we have been bitten
  a number of times by depending on old jQuery features as the rest of
  the web upgraded.
- Our impact on pages we load into is minimised. Previously, the
  bookmarklet had to load jQuery, unbind it, and restore the page's copy
  with jQuery.noConflict() (if it existed). Now the bookmarklet (and and
  future browser extension) can simply load Annotator.
- Code is more explicit -- the '$' token isn't assumed to come from the
  page context.

There are of course a few disadvantages:

- In the ideal case, a page author would already have included jQuery
  (at the correct version) and keeping the dependency external would
  have saved them from having to load jQuery twice.
- The tests are now slightly slower, as a result of having to build
  jQuery into our compressed source files.

Overall, I think this is a net positive change, as it makes deploying a
working copy of Annotator easier. In the long run, I'd like us to reduce
our dependency on jQuery completely, removing it altogether if possible,
and this is a first step in decoupling that process from the concerns of
3rd-party developers and integrators.
Merge pull request #338 from okfn/embedded-jquery

Embed jQuery in the built annotator
Revert "Remove redundant build writes"

This reverts commit 5a933ae8fffe1ef1ea349380976fc383515fecc4.

My mistake. This is what caused the libs to be written to pkg/lib.
This is needed for fine grained import of annotator from CommonJS
like browserify.
Add a useful DebugStore

This is usefull for debugging what's being passed through to the store
plugin.
Revert "Revert "Remove redundant build writes""

This reverts commit 8ac9c72f1e6497882136d629292691fa81057b63.
build pkg/lib on make pkg
Just require jquery

Now that I understand how browserify's `external` method works, this is
substantially easier.

Rather than having to proxy everything through `Annotator.Util.$` (which
is a good idea, if rather cumbersome) we can simply ensure that all the
code relies on the same embedded jQuery by externalising the dependency
on build using `external`.
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.
Remove unused file: console.coffee

This is no longer used by anything.
Standardise on require('foo') over require 'foo'

Sorry, this was getting on my nerves...
Restore standalone pattern and browserify plugin