[#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.
[#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
[#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
[#409] Organisation name on updates

The organisation name of the user who placed an update did not show on the update page.
Merge pull request #743 from akvo/feature/409_custom_user_model

[#409] custom user model
[#744] Test registration page
[#744] Bootstrap registration page
[#744] Playing around with Bootstrap navigation