A proof of concept wp-cli package directory.

The directory itself is a Git repo of `.yml` files. Each file (package listing) can have the following:
* Name
* Description
* Author
* Source

The 'source' should reference a publicly available Git repo. Packages are installed by cloning the Git repo.

The package directory can be initialized with `wp package update-directory`.

`wp package list` will list all available packages. `wp package install stat` will install the currently only available package in the directory.

The 'stat' command can then be used with `wp stat post word_count --start-date=2013-04-15`.

Pros to this approach:
* Package directory can easily be maintained with a Github account. Contributors can submit their own commands via pull request, and maintain their commands from their own repos.
* No running a build script, etc. after receiving a new package contribution. wp-cli reads the `.yml` files natively.
* Relatively easy to update from the cli.

Cons to this approach:
* Directory listing will always be N days old. Alternative could be publishing a JSON file on a remote server with a sucky build script.
* Only supports Git at the moment. If Git isn't installed on the server, things will break.
* Community commands are registered within the global namespace, but can't override core commands.
* Somewhat brittle directory structure at the moment.
* 'package' is the best worst name for a community command.
Update use of `format_items()` to support new arbitrary fields
Refactor package management to use Composer and packagist

* Packages are installed executing `composer require`
* Packages are removed by deleting the directory
* Packages are listed by executing `composer search wp-cli`
* Removes the previous Git-managed `.yml` directory approach.

@todo Commands are autoloaded but can't be run because `RootCommand::load_command` doesn't know how to find them.

See #424