Patch proposal for better database routing - see #701
Although I agree this is a pretty clean patch, I am going to pass on merging.

I think that database routing is a complex enough topic that I do not want to include it in peewee itself (as I don't want to maintain it). One option would be to create a new package `peewee-routing` or something similar that encapsulates this logic.
 Thanks for the quick reply! If I put myself forward as a maintainer for this, and submitted a fully documented PR, would you consider merging into playhouse? As a last option I could create a new repo, but would argue the use cases are common enough to justify being in the playhouse.
 I appreciate the offer and don't want to seem to be discouraging, but I'm actively trying to rein in some of the sprawl in the code-base and tighten things up. Database-routing, to me, both complex and uninteresting from a maintenance perspective. It is my strong preference to keep it out of this repo.
 Okay no worries, I'll look into creating a separate repo for this. I'll update the original issue with the URL once finished, if you're happy with it then (and agree with the approach used), then perhaps it might be worthy of a small section in the docs, so at least people know where to look?
 > then perhaps it might be worthy of a small section in the docs, so at least people know where to look?

I'm sure it'll turn out well, and I'd be happy to link it up.

After several different attempts, this seems to be the cleanest way forward. 

For this patch to be merge worthy, I'd need sign off from @coleifer on these questions about `Using()`. Also feedback from @stas and @alexanderad would be appreciated

This has minimal code impact as `_execute()` seems to handle every edge case, whilst ensuring that queries are still executed in the correct database order (to the extent of all tests passing, there /might/ be untested edge cases).

On the model there is now `determine_database`, by default uses the same SQL string inspection method as `read slave`, but in the event that users are making heavy use of raw queries with `IF()` conditionals, then they can extend to their hearts content.

There is also now `get_read_database()` and `get_write_database()`, by default these continue to use `self._meta.database` but can be modified to whatever the user wants.

The remaining problems now rests with `Using()`, as it does not support two database args. Altering the syntax with extra keywords would make it backwards incompatible, therefore I'd propose that we support the following syntax;

```
Using(database)
Using((read_database, write_database))
```

The last gotcha is whether `Using()` should override model, or visa versa. In my personal opinion, if someone has specified a `Using()` context then this should override whatever is in `get_read_database()` and `get_write_database()`.

From what I can tell, this /should/ cover all use cases from #701.
