Add chef_index_expand to flatten/expand and POST to Solr

The module allows us to process Chef objects in the
same way as the chef-expander code does, but now we can POST to Solr
directly.

The module also enables a bulk POST mode (not yet tested against Solr)
that should allow us to index or delete multiple objects using a
single HTTP request. For migration or re-indexing purposes this should
be a big improvement as we could easily reduce the number of HTTP
calls by 10x.
Capture key path as part of flatten/expand

Match the Ruby implementation to capture all steps of a key path as
KEY_HEAD__=__KEY_LAST.
XML escape quote character to match Ruby implementation

The Ruby implementation escapes `"` as `&quot;` so we need to do the
same. Note that this makes for some strange semantics if you have
embedded quotes and want to later search for them, you will need to
use the entity code in the search query.
Match behavior of Ruby implementation for embedded null values.

The Ruby implementation parses the null values in JSON to nil values
in Ruby which then end up as empty string when put into a format
string.

I'm not sure if our query transformation provides for a way to
generate a valid query. Arguably indexing the null value using the
string "null" might make for a better setup.

Conflicts:
	test/chef_index_expand_tests.erl
Improve floating point formatting to align better with Ruby

Floating point formatting in JSON may be difficult to match exactly.
This seems to get us closer to matching the behavior of the
chef-expander code.
Ignore generated files in test dir
Add meta fields to content to match chef-expander behavior

The Ruby based chef-expander adds db, id, and type values to the
content field. Pretty sure the system does not rely on this and that
no user is either. But in the interest of full backwards compat for
now, this makes the results match.
Add notes and scripts for correctness testing against chef-expander
Add init_add_items, add_item, and send_items API

The new API provides an interface to bulk item flatten/expand and POST
to solr. The interface is designed to allow either a serial
implementation or an async and parallel compute model for the
flatten/expand work (with a sync join on POST to solr).

The Solr URL is exposed as an argument to init_add_items/1 to make it
easier for us to test against multiple solr instances. In the future,
we may want to remove this argument and obtain the Solr URL from app
config.

* Cleanup command processing All POSTs to solr are now treated as
"multi" and sent inside <update>...</update>. This reduces some
special case code for dealing differentiating singleton updates from
multiple item updates.

* The output XML no longer includes newline '\n' after the
delete tag.

* Normalize error return for post_to_solr to be {error, _}

* Standardizing tagged error returns to be {error, _} makes it easier
to write consistent generic error handling code.

* Add doc and specs, rename init_add_items => init_items

* post_single and post_multi return ok instead of skip now when passed
no-op input.
Add md docs generated via `make doc`
Add info log before sending to solr
Add coverage for chef_index_queue:delete

Also some minor cleanup to the unit tests to do multiple ?assertEqual
calls rather than whole-sale pattern matching.
Allow Solr URL to be set in payload for via set/5 and delete/4

Current version of expander will ignore the value if present. New
version will post to the Solr URL provided.
Support multiple vhosts for set and delete

The previous patches allow calling code to pass a custom Solr URL to
control where data will eventually be POSTed given a single
queue (rabbitmq vhost) and single set of expanders.

This patch introduces support for multiple rabbitmq vhosts. A list of
vhosts can be provided in app config at 'rabbitmq_vhosts' (note the
's'). A bunnyc gen_server is started for each vhost registered under a
name derived from the vhost.

Calling code must now know the vhost it wishes to send to. This
provides for a different mechanism of simultaneously indexing data to
two different solr instances. Here, data is sent by the client to two
vhosts and there are then assumed to be two separate sets of expanders
each talking to a different Solr instance.
Expose chef_solr:search/2 to allow passing custom Solr URL
Align with current api
Overall pass/fail message
Add support for clients, nodes, roles, data_bag_items and environments