Story/28/alex

This is for #28, #37 and #8  and should be merged after #36 ( #27 )

## Settings changes:

 - While we wait for accounts, I've set up a ``USER_SPECIFIC_INFO`` variable in settings.py to simulate user specific plugin configuration.
 - ``PROVIDERS`` is now a list of provider paths with no care for their types.

## Provider changes:

* We used to initialise all providers, check for types and store them in lists at kick off. Now we're just going to import the relevant classes at the start and upon each request we'll use the relevant ones for that request. 
* Currently a "relevant" provider is defined as one whose name is present as a key in the ``'provider_config'`` key of ``USER_SPECIFIC_INFO``.
* Relevant providers are instantiated with the config settings at request time and passed in to the appropriate function (``get_feature_info``/``get_all_features``) who is responsible for checking whether they're implementing the right thing before calling.
* If a provider defines ``oauth_required``, the relevant key will be looked up in the current session tokens and returned. The github token resides at "github".

## Future thoughts:
* I'm thinking that the oauth stuff could actually just be another type of provider. So adding integration to a new oauth-required service would be pretty easy.
* Also wondering whether ``get_all_features``/``get_feature_info`` should just call the functions blindly without checking interface details, catching attribute errors.

If you agree with either of the *future thoughts*, I'll add them as issues to be done in this iteration...