[#409] Login with email or username using AuthBackend

Added a new AuthBackend in backends.py, making it possible to login with either email or username.

Using a regex it is first checked if the username is an email or username. Then the user is retrieved and returned if the password matches.
[#409] Replaced all direct references of the User model

All references to the User model have been replaced with django.contrib.auth.get_user_model() or settings.AUTH_USER_MODEL
[#409] Temp commit before merging migrations
[#409] Merging release/candidate into feature/409_custom_user_model

For resolving conflicting migrations.
[#409] Added schema and data migrations for new user model

The following migrations have been added:
- 0063: Adds the new rsr.User model
- 0064: Migrates data from auth.User to rsr.User
- 0065: Updates all user fields to use the rsr.User model instead of auth.User
- 0066: Deletes the rsr.UserProfile model

In addition, the auth.User model hasn't been deleted. This is possible, but backwards migration on this keeps failing.
[#409] UserProfiles partly removed

Most of the UserProfile mentions are replaced by the new User model. RSR and sign-in is working, several other parts need looking into (API, MyAkvo and probably some other parts).
[#409 #712] Added custom user model to admin

The auth.User model has been deleted from the admin, and rsr.User has been added, including the changes in the list_display as mentioned in #712.
[#409] Update models and admin

The username field is now renamed to username_old and no longer required.
username_old, first_name and last_name are now a ValidXMLCharField.

Also made some adjustments in the admin to display all fields correctly.
[#409, #715, #716] Registration process based on email

Registration process is now based on email instead of username. Usernames are still stored in the username_old field, new users will have their email address as a username.
In addition, user activation emails are updated.
[#409] Support project privileges for multiple organisations per user

Now that it is possible to have multiple (or none) organistions per user, the connected_to_user() function of a project is adjusted to cope with that.
#731 release notes for Hotfix
Merge pull request #732 from akvo/hotfix/731-releasenotes

No spelling errors it seems :)
[#409] Retain username field as main authentication

- Updated the registration form to take only 1 email address (which is the username)
- Updated migrations to retain username field
- Updated user admin to show API key

Additionally changed:
- Permissions on placing updates
- Removed the userprofile model
[#632] Add simple write permissions

Add rsr_rest_user_<model_name> permissions for all rsr models. This
requires the running of manage.py syncdb --all to get into the DB.

Add IsRestUserOrReadOnly and set BaseRSRViewSet.permission_classes to use
it. This allows users with the rsr_rest_user_<model_name> permission to
use the "write" methods of the API (POST, PUT, PATCH and DELETE).

Suggested use is to create a Group with the rsr_rest_user_<model_name>
permissions and assigin users that are allowed to write to this group.
[#632] More granular API permissions

Having realised the Up app needs permissions to POST to project_update I
decided to implement a first version of more granular permissions for the
API based on one permission per method per model.

Revise akvo.rsr.management.create_rest_api_permissions() to create one
permission for each of the four "writing" request methods POST, PUT,
PATCH and DELETE.

Add RSRModelPermissions which is based on
rest_framework.DjangoModelPermissions, but overrides
RSRModelPermissions.perms_map to match the perms created by
create_rest_api_permissions().

Set BaseRSRViewSet.permission_classes to RSRModelPermissions
[#632] Merge branch 'feature/632_rest_framework' into release/candidate
[#409] Fixed user permissions

User permissions are now in place, based on the new user model and incorporating multiple organisations per user.
[#409] Updated TastyPie API with new user model

The new user model is incorporated in the TastyPie API. The UserProfileResource has been deleted, so we have to check whether no one uses it. Other than that, the API remains similar to the current version. However, a user can also have multiple organisations right now. This is mostly visible in the project_update_extra resource, where all organisations of a user are now displayed.
[#409] Updated REST API for new user model

The REST framework largely remains the same as before. User profiles, however, have been deleted and project_update_extra now also shows 'organisations' field per user as well as the original 'organisation' field (representing the first organisation).
[#409] Merge branch 'release/candidate' into feature/409_custom_user_model

Conflicts:
	akvo/rest/serializers/__init__.py
	akvo/rest/views/__init__.py