RFC: Simpler API

@janl:
>Dale Harvey, “there are five ways to read data from CouchDB, it’s confusing” paraphrased

@nolanlawson:
>Some inspiration:
> * [pouchy](https://github.com/cdaringe/pouchy)
> * [rxdb](https://github.com/pubkey/rxdb)
> * [tote](https://github.com/jwalgran/tote)
> * [fun-pouchdb](https://github.com/jhs/fun-pouchdb)
> * [relational-pouch](https://github.com/nolanlawson/relational-pouch)
>
>Pouchy in particular is one I like a lot. :smile:

@daleharvey :
> So I see a lot of people asking which api should they use to get results from a database, we have get, `bulkGet`, `changes`, `revsDiff`, `allDocs`, `query/mapreduce` off the top of my head, each of those takes very different parameters, has very different performance characteristics and call almost be useful for very similiar situations.
>
> We actually do a decent job with writes, I am not so much opposed to the amount of ways to read but their inconsistencies, we can `put`, `post`, `delete` and `bulk_docs` but they are all consistent and can be implemented with `bulk_docs`
>
> In PouchDB I think we have generally agreed about moving towards `mango` / `pouchdb-find` queries, completely dropping `mapreduce` from core. Hopefully as that goes forward we can look at replacing some of the other core read APIs (allDocs, changes etc) with `find`. At the very least it means no adding new read APIs :)
>
> And I just remembered why this was brought up in the first places, someone asked for `allLocalDocs` and I would be hugely against that, we should be working on improving our current primitives (filtered replication), querying etc instead of adding new special case apis

Start with this RFC and compare the listed read APIs—get, bulkGet, changes, revsDiff, allDocs, and query/mapreduce—with the cited Mango/pouchdb-find inspiration. No files or tests are named; done would require a settled API design and an explicit decision on how existing read methods, including allLocalDocs, should be handled.

Written by the indexing model from the issue text.