Add a mixin for writing unit tests with custom models.

Django doesn't make it easy to write unit tests that have their own
custom models. The test runner has to add an app with a models.py file
to INSTALLED_APPS, and the models have to live somewhere within that
directory. This is a lot of work, and it's hard to keep things clean
this way.

This introduces a new mixin that can be used to allow a file containing
unit tests to define custom models. The classes that need to use the
models simply define the models within the file, use the mixin, and then
operate on them.

The mixin handles the hard work of sticking the module in
INSTALLED_APPS, loading the module, and also creating a fake 'models'
module to satisfy Django's requirements.

Reviewed at https://reviews.reviewboard.org/r/6245/
Allow unit test docstrings to wrap in Djblets tests.

This ports over Review Board's logic for unit test docstrings to
Djblets, allowing the first line of a docstring to wrap, in order for
more information to be provided.

Reviewed at https://reviews.reviewboard.org/r/6246/
Shuffle around the location of various Djblets tests.

When djblets.util got split up, most of the tests remained in
djblets.util.tests, which was getting pretty big. These have now been
moved out into more appropriate locations that match the modules they're
testing.

The djblets.db tests got split up into multiple files within thee
djblets/db/tests/ directory, in order to stay organized. Many of the
current and planned tests require a handful of extra model classes,
which was already making that file a bit confusing. With some work I'm
doing now, that'd get worse. By splitting this up, we can stay
organized.

Reviewed at https://reviews.reviewboard.org/r/6243/
Add support for using F() expressions in CounterField initialization.

CounterField intializers can now return a F() expression in the
initializer function, or provide the expression instead of a function,
instead of returning a numeric value. These will be passed to the
database query, allowing for atomic computation of initial counter
state.

Since we didn't have unit tests for CounterField before, this comes with
a set of tests for the new functionality and much of the original
functionality.

Reviewed at https://reviews.reviewboard.org/r/6242/
Add a specialization of CounterField for tracking model relations.

RelationCounterField tracks the counts on one end of a ForeignKey or
ManyToManyField relation, providing a convenient and efficient way of
operating based on how many objects are related to the model.

This takes a single parameter, which is the relation name. That can be
the field name of a local ForeignKey/ManyToManyField, or it can be
the related_name on the model that's provided by another model's
ForeignKey/ManyToManyField. For example:

    reviews_count = RelationCounterField('reviews')

When there are Django-initiated state changes on the opposite end of
the relation, such as newly added or deleted models, the counters will
update with the new count.

These counts should be accurate so long as the operations are performed
on model instances. Raw SQL queries will cause the models to get out of
sync. When this happens, the counts can be recomputed by issuing a
`reinit_<fieldname>` call.

RelationCounterField itself doesn't actually do much, aside from set
things up. All the magic happens in InstanceState and RelationTracker.

InstanceState holds information on a loaded model instance/relation name
pair, and all RelationCounterFields that follow that pair. It has
functions for operation on all the fields on a model following that
relation. (Normally there will be 1, but the design works out better to
just allow for more than one, since otherwise we actually have to track
more things to deal with conflicting state.)

RelationTracker is the real heart of RelationCounterField. There's one
RelationTracker for every model class/relation name pair. It figures out
information on the relation, listens to signals, and makes the
appropriate database and instance updates (using InstanceState).

Since Django's signals and API for all this are a little less useful
than I'd like, there's a lot of calculations that have to go on and some
state tracking we have to do. I've tried to document how it all works,
but there's likely room for improvement.

Unit tests were written to handle every case I could throw at it, along
with ensuring all query counts are consistent with what I'd expect.

Reviewed at https://reviews.reviewboard.org/r/6248/
Merge branch 'release-0.8.x'