Django integration take 2

Hi @rdegges  here's the work in progress for the django integration. 
As was discussed in the previous issues/pull-requests you can now do something like:

    from django.contrib.auth import get_user_model
    UserModel = get_user_model()
    UserModel.objects.create(
        email='john.doe@example.com',
        given_name='John',
        surname='Doe',
        password='password123!')

This will create a user in the local database and on Stormpath as well. There are other variations of this example in the README as well.

For instance:
    python manage.py syncdb (or createsuperuser) 

This will also create a user account on Stormpath.

One thing to note is that I'm using the `transaction.atomic` decorator/context-manager to ensure atomicity. This was added in Django 1.6 so the current implementation doesn't work with Django 1.5 (the first release that supports custom user models). I'm not sure this is an issue since Django 1.7 is the latest stable now. I would like to hear your thoughts on this matter.

You can tests all of this by using the `testproject` in the repo. Be sure to set the environment variables in `.env` alongside `manage.py` so that the configuration can be read.

Example `.env`:
 
    STORMPATH_ID = tenant id
    STORMPATH_SECRET = tenant secret
    STORMPATH_APPLICATION = app-href

One more thing to note is that the authentication backend will create new users in the local db if they don't exists yet, and it will also, upon successful authentication, update the fields in the local db for that user from the Stormpath Account. Passwords aren't stored in the local db...the password field is required on the model (by django's design), but we make sure to store an invalid value via supplied django mechanics. That way the authentication will only happen via Stormpath even if the system is misconfigured to use, for instance, the default ModelBackend.

The project supplies django admin integration as well. So you can add/change/delete users in the admin interface and it should all reflect on Stormpath as well.

We store Django specific properties (like `is_staff` and `is_superuser`) in the Accounts CustomData Resource. So for a new Account created on Stormpath to be able to log into the django admin interface it needs those 2 flags set. The best way is to create all users either through the admin interface or using the `create_user` and `create_superuser` methods and they take care of all of this. The `is_active` mirrors the Account.status field.

I'm not entirely sure I'm fully satisfied with the code, some parts could be written more concisely perhaps. I would be glad to hear your thoughts on that as well. But it's a working prototype. 
We need to add tests as well, just o be sure we haven't missed any edge cases that could leave us in an inconsistent state.