Theme support + Changed versions detection

Fixes issue #3 (theme support)
Fixes issues related to versions: #7 #10 #20 #28

**Heads up**: This is a very big PR rewriting a large part of the project. Everything is detailed below and I am opened to split things up if necessary.

### So much themes, so fun, so classy !

1. All themes are now available using `wpackagist-theme/THEME`
  * In my tests, I saw that some old themes are not hosted anymore, their download page redirect to the themes index page, but they are still in the SVN. This causes composer to download the HTML of the index page as if it was a ZIP file and crash weirdly. However, I don’t think this is a big issue as you should probably not be trying to download a deactivated theme.
2. Plugins are now available using `wpackagist-plugin/PLUGIN`
  * The old `wpackagist/PLUGIN` is still working properly but is now deprecated.
  * However, if you change `wpackagist/PLUGIN` for `wpackagist-plugin/PLUGIN` in your `composer.json`, you will have to run `composer update` 2 times because it will delete itself on the first pass.
3. Documentation in `index.html` and `README.md` was updated accordingly.
  * N.B. The plugins used in example were changed because the names were too long for the box.

### Heavy internal redesign

1. Adds a package abstraction layer:
  * `AbstractPackage`
    * `Plugin`
    * `Theme`
2. Database changes
  * Name changed from `data/plugins.sqlite` to `data/packages.sqlite` to better reflect its new content.
  * New column: `class_name` which the fully qualified class name. This is to use `PDO::FETCH_CLASSTYPE`
  * The primary key is now `(class_name, name)`
3. It is no longer possible to pass the base SVN url in parameter
4. All the JSON generation logic is moved from `BuildCommand` to `AbstractPackage`
5. `provider-includes` were changed to lessen the payload to be updated each time. Last method had a lot of files for each year and you had to download the whole current year each time any plugin was updated. The splitting was decided empirically by checking the size of the generated files.
  * last monday
  * first day of 2 months ago
  * first day of this year (will not exist if we are past March 1st)
  * first day of last year
  * the rest

### Changed versions detection

Versions are now parsed from the developers tab of wordpress.org. I was having a lot of issues with fetching versions for projects that were not valid (incorrect readme, etc.) so I decided to put everything into the same PR.

I tried to use Wordpress.org APIs but do not list versions history: http://codex.wordpress.org/WordPress.org_API

  * Advantages:
    * Checks for invalid and inactive plugins (and ignore them until next SVN commit)
    * Plugins using `trunk` directly (without tags) are now properly supported
    * Use the parsing mechanism of wordpress.org, which is more robust	 
  * Disadvantages:
    * Much slower
    * Subject to changes without notice