Grooveshark

This IE is ready to go as soon as HttpFD supports POST. There are several redundant keys to support various possible POST implementations, but if you have an idea for a specific interface convention you'd like me to honour, do let me know. Specifically:
* `post_dict` is a dict of strings not url encoded,
* `post_data` is `post_dict` as a url-encoded string (`headers['Content-Length']` refers to this),
* `headers` contains `Content-Type`, `Content-Length`, and `Referer`
* `req` is a urllib Request prepared and ready for execution

I also added an overload of `_download_json` with a `fatal` parameter, since I did have a non-fatal JSON request. Maybe this could be implemented in the parent class? I'm not entirely sure my logic there will play nicely with the other download helper methods.

The first two steps in `_real_extract` are non-essential, but they seem to allow more requests before the servers start "suspecting". (Since they represent the usage pattern of the webapp itself, they're probably useful just to avoid long-term vulnerability to log analysis.) However, they are switchable with:
```
do_playerpage_request = True
do_bootstrap_request = True
```