The way that SCMTools are kept track of is particularly old. From the

very earliest days of Review Board, we knew that we wanted to support

multiple different SCMs, and we had done this by creating a Tool model

which had a name and the module path of a class to instantiate. This was

populated via database fixtures, and Repository then had a relation to

the tool.
As we improved things and made everything extensible, we moved away from

fixtures and over to entry points, but this still had two major

problems:

If there's a VersionConflict in the install, no entry points will

   load.
There was still a manual step that had to happen to load the tool

   types from the entry points and populate the Tool table.

   Occasionally, usually due to problem #1, people would end up with an

   install that didn't have any Tool models, and we'd have to direct

   them to manually run the registerscmtools command.

This change is the first major step towards modernizing this entire part

of the system. This adds a new registry for storing the SCMTool classes.

By default, this is populated from three places. First, we load the

built-in SCMTools (whether or not entry points can load). Second, we

load anything present in entry points. Finally, we'll go through the

existing Tool table, and load anything else from there (while printing a

warning that said table is going away, and anything there will need to

be changed to use entry points or the register() method directly.

Checked that the registry was properly populated from built-ins and

  entry points.
Created a fake item in the tool table and populated the registry. Saw

  that it was added to the registry and the appropriate warning was

  raised.
Removed an item from the Tool table. Re-populated the registry and saw

  that the Tool instance was properly created.
Ran unit tests.