DO NOT MERGE Bug1003527 split schema

**This is for discussion/review.** 
I've still got a bit of work to do yet, but this is how things might look in the future!

**ALSO** I'm working on a diagram that explains this a little more to help with the review.

Goal: Create a schema divided between `base` tables like:
* raw_crashes
* processed_crashes
* reports

And provide target tables accessible via the `postgres_fdw` and a new schema called `normalized`. `setupdb_app.py` automatically creates the `FOREIGN TABLES` to write the normalized output to a remote database that has a schema that looks a lot like what we have today, but without the `base` tables -- or with more `FOREIGN TABLES` that can remotely access the `base` tables. Our plan is to have multiple databases containing `base` data, so we probably need a combination of changes to the middleware and Django front end to enable access to `base` data, and additional `FOREIGN TABLE` definitions.

We will then run a subset of stored procedures on for normalizing data in `reports_clean` and all the other "fact" tables. Most other "raw data" tables would continue to reside on our reporting database because they are so small in comparison. (this is likely coming down to TWO stored procedures: `update_reports_clean` and `update_reports_duplicates`)

## Discussion points

* Should we segment schema based on product or group of products? Like `collector`, `processor`, `middleware`, `webapp`?
* **Bikeshed opportunity!** - Are there better/more meaningful names for the schemas?

## Details
There are three major sections of schema: 

* base
* normalized
* public (reporting tables, basically)

I think what we want to do is at something like: `SET search_path = base, public, normalized, public` to our connection context objects to make finding the tables easy for SELECTs, rather than hard-coding all the schema paths into our queries. Need to do some experimenting to see exactly where and when the best place to do this would be.  (probably just our `connection()` object in the `connection_context.py`)
There's a lot of hacking at the `models.py` that went into this -- but they are largely "template" changes... moving around things and adding the `schema` attribute to `__table_args__`. 

This patch can't get much smaller, but once you look through it I think the pattern of changes is somewhat obvious.

The phases of changes probably can be broken up by: 
* Enable separated schemas
* Adjust tests and crashmovers/processors to connect only to the `base` table database for a subset of tests
* Adjust middleware/webapp to connect only to non-`base` database

## Work left to do

* Tackle the "base" tables the same way that I've handled the "normalized" ones, with separately named classes and duplicate classes in the 'public' schema for when we are operating with just a single database. This simplifies the testing and any additional refactoring needed for a default install of Socorro that only has one database.
* Following that same train of thought, we might have different stored procedures invoked for the single-database schema vs multi-database schema. Building the logic into the stored procs seems ... like a recipe for excessive complexity.
* Needs tests to verify that two databases are actually created by setupdb_app.py and that the new schemas exist etc.
* Take a cue from `PolyCrashStore` and make it easier to configure multiple databases to connect to. The current implementation adds `primarydb` and `secondarydb`. I think it'll probably be better in the long run to have a "multiple databases can be configured" mentality, with some attributes like whether the databases are read-only, and which schemas we want to have on them defined in the config.