3.0 - Extract table registry

This set of changes separates the static and non-static features of `Table` into a separate Registry. The registry provides a similar interface as the other static registries, and allows Table to remain simpler.  `TableRegistry` also makes it simple to resolve tables lazily, and doesn't prevent cross connection associations if we want to avoid them in the future..

I've added a feature to automatically force all table objects to use test connections instead of the 'real' ones. I've called it connection aliasing, and while the name may be a bit wonky, I think it provides a nicer solution to this problem than we used in 2.x. By making it much harder to access the 'real' connections it is less likely that a developer will accidentally hit the wrong database in testing.

### Alternative approaches

One alternative I considered was to make connection instances have a `getTable()` method. This would remove the need for yet another static class and allow the following type of usage:

```php
<?php
$db = ConnectionManager::get('default');
$tasks = $db->getTable('tasks');
$q = $tasks->find('all');
```

All tables would inherit the connection, and any associated tables would inherit the connection of the table they are connected to. This has the benefit of not requiring any static classes, but obviously prevents associations between connections. 

I'm not sure we really want to support cross connection associations as they have always been problematic and buggy in the past. This approach might also complicate accessing models from a controller as you'd need to define both the connection and table you want. These are the reasons I didn't pursue this approach. However, if we can come up with an elegant way to expose table getters in controllers I think it is worth having fewer static classes.