Fix broken links to user page URLs in certain cases.

When Review Board is installed *not* at the root of a server, say,
/reviewboard/ , the user links are broken. This happens in many places
where User Links are obtained, for e.g. a) when searching, b) change
description links when a user is changed in the Review Request.

The application tries to use Django's User.get_absolute_url(), which
always returns /users/<username> ignoring the application path. This
patch fixes this in 2 places

a) Adding a serialize_url_field to UserResource. This would fix all API
   calls

b) Adding a ABSOLUTE_URL_OVERRIDES section in settings.py for auth.user.
   (https://docs.djangoproject.com/en/1.4/ref/settings/#absolute-url-overrides)

We could have skipped (a) above by just adding ABSOLUTE_URL_OVERRIDES
alone as djblets' serialize_url_field calls User.get_absolute_url and
(b) would have solved it, but this doesnt take  localsites into
consideration. Actually (b) above doesnt work with localsites, but then
I found that localsites are not very well handled in other pages as
well. For e.g. in the dashboard of a localsite, if you try to search for
reviewrequests for a particular localsite, it doesnt show that because
the url being searched is only /api/search, not s/localsite/api/search
(If I run the search for s/localsite/api/search, it returns results
correctly). I will file a separate bug for that , but once that is
fixed, the solution (a) above is more correct because it takes localsite
into consideration.

This patch should fix problems for all users who dont use localsites.

Reviewed at http://reviews.reviewboard.org/r/3836/
Add new API for working with default reviewers.

We never had API for default reviewers before, meaning that it was
impossible for scripts to query or manipulate them.

This introduces POST, PUT, DELETE and GET support for default reviewers.
The functionality is pretty standard. Querying the lists, though, has
some nice filtering to narrow down by repositories, users, and groups.

To get the errors to propagate correctly, DefaultReviewerForm has been
updated to tie any user/group/repository validation errors to the
appropriate fields.

33 new unit tests were added.
Merge branch 'release-1.6.x' into release-1.7.x
Actually delete repositories through the webapi when they're empty.

If you delete a repository through the API, it doesn't actually delete it, it
just "archives" it (sets it to be invisible and changes the name). The reasoning
behind this is that we don't want to break any existing review requests.
Unfortunately, if you then try to create a new repository with the same path, it
will fail due to the unique_together constraints. This keeps hitting users of
RBCommons, where the API is the primary way that repositories are
managed--what's happening is that users create a repository and as they're
trying to get things working, they delete it. They then recreate it and hit a
constraint error.

Instead of blindly archiving, we now only archive if we actually have review
requests to preserve. This doesn't fix every possible case (maybe someone
created a test review request and then deleted the repository) but it should
handle most of the failures I've seen so far.

A better fix would be to do constraint checking by hand and only test for
uniqueness among visible repositories, but that involves schema changes.

Testing done: Ran unit tests. Verified that a DELETE call did what I expected.
Reviewed at http://reviews.reviewboard.org/r/3880/
Merge branch 'release-1.6.x' into release-1.7.x