Additional configuration for consumer bindings

Two new fields have been added to consumer bindings:

* notify_agent controls whether or not the agent for the indicated consumer will be sent a message about the new binding. This defaults to true to maintain the existing functionality prior to this addition
* binding_config is saved for the binding itself and passed to the distributor's consumer payload creation call. This is in addition to the existing "options" field which may be used in the future for the agent's running of the bind call.

The bulk of the changes were to unit tests. The following is a high level overview of where in the server code changes were made:

* The Bind domain object was updated to store these two new fields. A migration was written to default these for existing consumers.
* The distributor manager was updated to accept the fields and save them.
* The distributor manager was updated to retrieve the bindings and send them to the distributor in the payload generation call.
* The Distributor base class API for the payload generation was updated to accept the binding_config as a parameter.
* The bind itinerary was updated to both accept these new fields and take advantage of the notify_agent option, skipping the creation of the agent task if necessary (this was very cool how easy this fit in)

As a Distributor base class API changed, there will be a corresponding pull request in the pulp_rpm project for the yum_distributor which uses this feature. Neither the puppet distributor nor the ISO distributor overrode this method in the first place and remain untouched.

The REST API documentation has been updated to include the new fields.

This pull request does not address the rebind approach. Currently, a call to bind a consumer that has already been bound will not appear as a conflict but will instead act as an update. The manager code has been adapted to save these new fields in that event and otherwise proceed with the existing workflow.