Update broker plugin API

Modifies the behavior of the broker plugin API to support additional
broker plugin types. Each plugin type may require configuration
parameters that are unique to its implementation.

Borrowing the add/update pattern from the model slice, each broker
plugin type will get its required metadata either interactively (if the
action is performed via the CLI) or from an associated JSON hash of
metdata key/value pairs (if the RESTful API is being used).

The updated `broker add` CLI usage is:

    # razor broker add --help
    Usage: razor broker add (options...)
        -p, --plugin BROKER_PLUGIN       The broker plugin to use.
        -n, --name BROKER_NAME           The name for the broker target.
        -d, --description DESCRIPTION    A description for the broker target.
        -h, --help                       Display this screen.

And the corresponding `broker update` CLI usage is:

    # razor broker update --help
    Usage: razor broker update (UUID) (options...)
        -n, --name BROKER_NAME           New name for the broker target.
        -d, --description DESCRIPTION    New description for the broker target.
        -c, --change-metadata            Used to trigger a change in the model's meta-data
        -h, --help                       Display this screen.
Beginings of chef broker. Right now, chef server info is hard-coded into agent_install.rb, but it should work to deploy node with chef client installed and register with chef server.
Changed static server variable to use the one stored in the broker
Fixed server variable in chef broker. Also corrected broker success status
Update Chef broker to new plugin API and add metadata.

The following metadata items are added to the Chef broker:

* chef_server_url - the URL for the Chef server
* chef_version - the Chef version (used in gem install)
* validation_key - the contents of the validation.pem file
* validation_client_name - the validation client name
* bootstrap_environment - initial Chef environment for node
* install_sh_url - the Omnibus installer URL
* chef_client_path - an alternate path to chef-client binary
* base_run_list - an optional run_list of common base roles

The rendered bootstrap template is no longer written to the client node
as it contains sensitive data (validation.pem contents and future
encrypted data bag secret). Instead the resulting template is logged on
Razor's debug level is debugging is required.
Update agent_install terminology to chef_bootstrap for Chef broker.
Update ProjectRazor::Slice::Broker specs to match API updates.

Previously, specs were highly order dependent and coupled, whereas now
each spec is isolated from other tests.

One spec remains pending as it is likely no longer a public API call
that is supported (creating a broker target via GET).
Refactor ProjectRazor::Slice::Broker specs.
Added details for razor node
Merge pull request #2 from eglute/feature/master/chef_broker_details

Added details for razor node
Adding broker details to be printed out by get_broker_by_uuid for both puppet and chef
Merge pull request #3 from eglute/feature/master/broker_print

Adding broker details to be printed out by get_broker_by_uuid 
Validate URLs in Chef broker with URI::DEFAULT_PARSER.regexp.

This regular expression is one used internally in Ruby's stdlib to parse
URIs in URI.new.
Update Chef broker node attribute key razor_details -> razor_attributes.
Use more posix-friendly 2>&1 stderr redirection in Chef broker.
Fail Chef broker bootstrap if neither wget nor curl is found.

The simple failure case is to report an error and return a nonzero exit
value.
Add note to Chef broker template, referencing chef-full.erb template.
Document Chef broker validation.pem creation & remove temp file step.
Add note in chef_bootstrap.erb to inspect Omnibus installer script.
Modify form of Chef run_list items that are Razor tags.

Razor tags have a restricted set of valid characters, so square brackets
and colons will not work out of the box.