ScriptCollection

Adds support for ScriptCollections, i.e. collections exposed by resolvers.

Another pull request in tomahawk-resolvers adds ScriptCollection support to the Subsonic resolver.

Highlights:
* Capabilities support, for resolvers to declare whether they support features such as ScriptCollections.
* Moved collection/dbcollection/resolvers stuff around a bit so it (imho) makes more sense.
* ScriptCollection inherits from Collection, much like DatabaseCollection; both allow to request artists, albums and tracks by acting as factories for objects accessed through abstract base classes Artists/Albums/TracksRequest.
* ScriptCommands are job classes that represent a resolver operation other than track resolution, much like DatabaseCommands.
* DatabaseCommand_AllArtists and ScriptCommand_AllArtists implement ArtistsRequest, DatabaseCommand_AllAlbums and ScriptCommand_AllAlbums implement AlbumsRequest, DatabaseCommand_AllTracks and ScriptCommand_AllTracks implement TracksRequest.
* ScriptCommands always report an answer, either from the resolver or because of a timeout, and are executed sequentially thanks to ScriptCommandQueue.
* There is a bit of friending going on that obviously breaks perfect OO but imho makes sense in order to disallow ScriptCommand execution outside of ScriptCommandQueue.

TBD:
* ScriptCollections are currently shown under the *local* SourceItem, as "$RESOLVER_NAME Collection", is this the best way/place to show them?
* ScriptCommandQueue should be thread safe, because a new ScriptCommand could be enqueued at any time, and the current ScriptCommand could finish at any time, I'm not sure I have ensured thread safety successfully.
* There should probably be a way for the user to "refresh" the collection.

Please review and test, and try to break it.

![screenshot1](https://f.cloud.github.com/assets/126364/124468/d8092dea-6eef-11e2-8930-2ef8fef20c5d.png)