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: 1. If there's a `VersionConflict` in the install, no entry points will load. 2. 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. Testing Done: - 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.