We hit some confusing issues when running selective Review Board test

suites with the introduction of registry-backed SCMTools.
Basically, when exclusively running certain test suites (ones that do

not use the test_scmtools fixture on the class level, but do add it

for selective tests through the use of @add_fixtures -- for instance,

./reviewboard/webapi/tests/test_review.py), we'd end up in a state

where the fixture would try to apply on top of tools injected into the

database through the registry. This is actually more the "correct"

behavior, as opposed to test_scmtools applying on top of nothing, but

it's the case that broke tests.
The problem has to do with registry setup, when the registry adds to the

database, and when fixtures load. The process is this:


The first thing a test suite does is call Django's setUpClass(),

   then load class-defined fixtures, then call _fixture_setup() (which

   we override to compile and load fixtures -- too late and redundant on

   modern Django), and then setUp().


Any test_scmtools fixtures are injected in Django's setUpClass().

   This gives us a common database entries used by all tests in the

   suite (using transactions/rollbacks to get back to that state). If

   that fixture is not used, no entries will be in the database for

   these tests.


We register some test tools in our own setUpClass(), which triggers

   registry population. If test_scmtools was used, this does

   effectively nothing (though it will register entrypoint-provided

   tools). If it was not used, then this will inject its own common

Tools entries in the database.


We then get to our _fixture_setup(), which used to be where Django

   managed fixtures on a per-test basis. Djblets overrides this to do

   fixture compilation and loading (which doesn't work as well with

   modern Django) and loading of anything provided by @add_fixtures().

   Once again, any fixtures are loaded and injected into the database.

   If test_scmtools is used here, this is almost a no-op, as

loaddata (which loads the fixtures) will ignore any identical

   matches in the database. If test_scmtools is not used on the class

   level, nothing happens here.


Now we get to @add_fixtures(). This will try to incrementally add

   the fixtures to the database. If used on a test function, the

_fixture_setup() for that call will load in any fixtures provided.

   If we use test_scmtools here and on the class level, nothing

   happens, since loaddata will see the data is the same. However, if

   the initial state was populated by the registry, this will fail, as

   the data won't match up. It'll conflict.


There's a bit of a chicken-and-egg problem here. Confusing, but the

solution is to treat our registry as the source of the fixture:


The test_scmtools fixture is now empty. The fixture itself must

   remain for compatibility reasons, but it no longer needs content.

   It's simply an identifier.


The SCMTools registry has a new function for the database population,

   called populate_db(). This is still called by populate(), but

   we're able to use it to force a re-sync of tools.


TestCase.load_fixtures() (called by _fixture_setup()) now looks

   for test_scmtools, removes it from consideration, and then tells

   the registry to populate via populate_db(). This gives us one

   source of truth, and one place (setUpClass()) to manage suite-wide

   population of registered SCMTools.

All unit tests passed.
Ran selective unit test suites and individual tests that were previously

failing. They now pass.