Preliminary commit for browserify compatibility

This is the first stage of my commits for issue #609 that will make the
npm module browserify friendly and browser friendly.

The grunt-browserify module has been introduced to replace
grunt-contrib-concat. Browserify automatically concatenates files and so
there is no need for a concat step.

The faye-websocket module was problematic so I moved the require out to
a separate module within the lib directory. The websocket module is a
folder containing a package.json, directing library consumers to the
entry point that is appropriate for their environment. Browserify picks
browser.js (which simply returns an object holding window.WebSocket)
while everyone else gets the faye-websocket module.

In addition, as browserify handles all the requires, there's no need to
detect the environment or include any pre-built modules. I've removed
the pre-built when and faye-websocket files in favour of letting
browserify use the modules within node_modules. This should make it
easier to maintain dependencies in future versions of this library.

One side effect of this browserify compatibility is that, in order to
allow the library to be globally available in the browser as `Mopidy`,
I've had to set Mopidy as the exported object instead of as a key of the
exported object. To elaborate further, the current API would be like the
following:

    var Mopidy = require('mopidy').Mopidy;

However, with this change, the API would be like this:

    var Mopidy = require('mopidy');

I'm not sure whether this would be an issue and so I think it's worth
discussing further. It's possible that node developers won't have a
problem but, if they did, a potential workaround within the mopidy.js
file would be:

   Mopidy.Mopidy = Mopidy;

This would allow developers to choose either of the following:

    var Mopidy = require('mopidy');
    var Mopidy = require('mopidy').Mopidy;

Could be a little odd to do this though

When testing the browserify build, I noticed a strange error thrown when
making the initial websocket connection. I managed to track it down to
an IE 'feature' that crops up when you alias in-built functions. In
particular, the when module was aliasing setImmediate to an internal
function (nextTick.) In a newer version of when, the function is
instead aliased to the browserify process.nextTick. This works well
because substack already had that covered.

With when@2.7.0, IE11 appears to be working well. IE10 is still pending
a test.
Update test so that it correctly requires the mopidy module

As part of issue #609, the require statement in mopidy-test.js should
have been updated as the API to require mopidy has changed from:

    require('mopidy').Mopidy;

to:

    require('mopidy');
Updated the test process for mopidy.js

Following on from the previous issue #609 commits, I have updated the
build process to cater to the fact that the files are no longer
available to test in the browser environment.

2 new browserify tasks build the mopidy.js file and then when.js file
(available in node_modules.) These files are placed in test/lib/ (This
directory has been added to the .gitignore file) prior to the running of
the buster tests. As these files are ignored in the .gitignore, this
will prevent them from being committed to git and also prevent them from
being packaged up to npm.

Once the tests have completed, the main browserify task will run to
build the official browser release.
ext: Convert commands to use new registry system.

Creates a placeholder registry using the existing hooks, and updates the
commands to use these. The actual registry still needs to be created.
ext: Add basic global registry and switch to Extension.setup()
local: Add local/data_dir config value.

Not in use yet but, needed for future changes planed in this branch.
ext: Move away from global registry to ease testing.

Extension's setup method are now passed the active registry allowing them to
"steal" a list of the registry items they care about. In the case of commands
the registry is passed via args.registry.
local: Add new library interface to local backend.

This forms the basis of our plugable local libraries that we intend to ship.
local: Remove local-json as a split out extension.

Will be re-added using the new library interface. This commit does break tests.
local: Add local library provider back

- Re-add a local library provider that uses our new library interface
- Re-add our json library using the new interface
- Hardcode these to use each other for now
- Scanner bit is still missing, will re-add in one of the next commits
- Bypassed test for #500 for the time being
local: Add local/library config value

- Updated library provider to support missing library
- Added config value to select local library provider
- Updated tests to use library config value
local: Update library interface

- Add track iterator for use in scanner
- Update lookup to only return a single track
local: Update scanner to use new library interface.
local: Make sure excluded file extension case does not error out
audio: Workaround fact that genre can sometimes be a list
local: Review comments
Merge branch 'develop' into feature/extension-registry
local: Update local library interface.

Refactored interface to incorperate lessons learned so far trying to implemend
a whoosh based local library.

Search now has a limit and an offset to account for fact that we need to start
doing pagination of results properly. Updates now have begin, flush and close
calls. Additionally I've added clear method to allow for easily nuking the data
store.
local: Add flush threshold to scanner.

Instead of triggering every 1000th query, this is now configurable and also
triggers the flush call to the library.
local: Add --clear flag to scanner.