Test framework for UI + SQL tests

@nockertsb please review
Timber requires us to register a `Tree` which determines where the output will go. So normally we register a `DebugTree` in development which outputs to CatLog. We could do the same here, but idk what the lifespan is in this sense (since Timber is static) and I figured long-term it would be messier.

Also of note is that since the Timber instance in the app is in a different process than the instrumentation tests, we can't actually modify the Timber instance used in the app code from the instrumentation test. Which means we can't do things like register another tree to verify certain logging messages are fired by the app for example.

Normally i'd say no, it's not worth logging things in tests but I did this time b/c it potentially iterates over many migrations, and just having the test fail is unlikely to provide enough info as to what happened. I hoped that printing the migration version might help. Not attached to it though if you'd rather it be removed.