use yokozuna or riak_search for {search, ...} MR inputs

There are two ways to use riak_search inputs for MapReduce:
 * specify a {modfun, ...} input ({"module":...,"function":...} in json)
 * specify a {search, ...} input ({"bucket":...,"query":...} in json)

This patch allows yokozuna to power the second type instead of
riak_search. The value of the "bucket" field is used as the name of the
yokozuna index.

This patch does not convert the modfun version, to keep from surprising
users, and to allow an escape hatch for people that need to use both.

If only one of riak_search or yokozuna is enabled, that system is chosen
to power search MR inputs.

If both are enabled, then the riak_kv's appenv 'mapred_search' must also
be defined as either 'riak_search' or 'yokozuna'. If it is not defined,
or it is defined as something else, and error will be returned from the MR.

If neither is enabled, an error is returned from the MR.

The automatic nature of the switch is intended to keep configuration as
minimal as possible: the extra riak_kv setting is only needed if *both*
riak_search and yokozuna are to be used, *and* the user wants to use the
non-modfun forms. If only one search system is enabled, or only modfun
input forms are used, the correct thing just happens.
allow "index" in search MR inputs

this is to help yokozuna distinguish between when the user mean to use
the bucket name or the index name for searching

if "index" is used, the modfun is given {index, Index} instead of Bucket
as its argument
make riak_search default mapred search provider

if both riak_search and yokozuna are enabled, but the
riak_kv:mapred_search appenv has not been set, default to riak_search
only use mochijson2 format for search mapred index spec

this is the only format that can be passed in using the modfun input
style, and we'd rather not have multiple internal representations, so
{index, Index} is out
Merge remote-tracking branch 'origin/develop' into feature/bwf/mr-switch
Fix permission for map-reduce/search

The case statement was erroneously re-using the function parameter
`_Query` as an ignored variable in two of the case clases.  The
`_Query` function parameter and the `_Query` in the search tuple are
two different things and thus will never match.
Simply treat Bucket as Index

Abondon the idea of having an implicit lookup from bucket to index
when using Yokozuna to drive search input to map-reduce.

This is a very long-winded commit message because the subject matter
is confusing.  Scroll to end for TL;DR.

Riak Search and Yokozuna can both be used as engines to produces
results for a search input to a map-reduce job.  For example, in
pre-Yokozuna days if a user specified the following HTTP JSON
map-reduce job Riak Search would be used to run a query against the
"bucket" foo.

"inputs":{"bucket":"foo", "query":"bar"}

Calling it bucket is really a misnomer because what is being searched
is actually an _index_ of bucket foo.  However, since Riak Search
forced a 1:1 mapping from bucket to index name there wasn't much of a
difference.  The possibility of a M:1 bucket to index in the future
was never considered.

Fast forward to today.  There are two search systems in Riak now.
Yokozuna will eventually replace Riak Search but for the time being
there will be migrations from one to the other.  Furthermore, Search
APIs have already been exposed that assumed the functionality of Riak
Search, which is a small subset of Yokozuna.  Therefore, Yokozuna must
work around these weird cases.

In this case, passing the previous HTTP JSON map-reduce to Yokozua,
the user might expect 1 of 2 behaviors.

1. A bucket has an associated index.  Get the index from the mapping
and run the query against that.

2. Since the input should have been an index name to being with, and
1:1 mapping was just a coincidence in Riak Search, then simply treat
the 'bucket' input as the index name to search against.

The first option might seem like the most obvious but what if the user
decided to index multiple buckets under the same index?  The results
would now include results from other buckets.  An implicit filter
could be added to the query but we've started introducing more
implicit (magical) behavior.  Furthermore, under the covers, it
complicates the code.  For security purposes do we check for
permission on the bucket, on both?  But even if that wasn't enough,
things get EVEN STRANGER when you consider that you can use 2i as
input to a map-reduce job with the following JSON.

"inputs":{"bucket":"foo", "index":"field1_bin", "key":"bar"}

Hey, I know, we could overload this "inputs" field even more and
covert the following into a search request.

"inputs":{"index":"foo", "query":"bar"}

But if we chose option #1 from above we have a problem here.  The
Yokozuna code needs to know if the incoming search request is using an
index name or a bucket name.  If the later if needs to lookup the
index to query.  But in order to do this the Riak KV code needs to
create a new data structure to pass as the "Bucket" parameter so that
the Yokozuna callback knows which is which.  Does this sound very
confusing?  I hope so, because it is!

So after a long talk with Bryan Fink we decided to stop trying to be
cute and just face the fact that "bucket" was a poor name for the
input structure.  Just pretend it is actually "index" and Yokozuna
will treat it as such.

TL;DR;

If you are migrating from Riak Search then you should make sure to
keep a 1:1 mapping for bucket to index if you don't want to change
your map-reduce input.

If you are starting fresh then just use the new JSON format feed
map-reduce with Yokozuna.

"inputs":{"index":"foo", "query":"field1:bar", "filter"field2:baz"}

(Note that "filter" is optional)
Merge pull request #664 from basho/feature/bwf/mr-switch

Use yokozuna or riak_search for "search" MapReduce inputs