[Breaking] Introduce Providers to support chef-client & puppet.

Note that work on Providers is ongoing and not feature-complete as of
this commit. Tread lightly, y'all.

New classes/objects:

* Kitchen::SSH - Helps maintain a persistent connection with an instance
  between commands and transferring files. Its only concern is running
  remote commands, transferring files and managing its connection.
* Kitchen::Provider::Base - Base class for provider implementations.
  Base methods that may be implemented will be documented here.
* Kitchen::Provider::ChefSolo - Pulls together code and logic formerly
  in Kitchen::Driver::SSHBase and Kitchen::ChefDataUploader. Its concern
  is implementing the method contract of a Provider, that is providing
  methods returning strings that can be passed to an SSH connection,
  serial connection, or external shell out binary. It is also
  responsible for creating the Chef artifact sandbox containing
  cookbooks, roles, data bags, etc. which can be used by other
  components to transfer to a remote system.

Retiring classes/objects:

* Kitchen::ChefDataUploader - In the wake of splitting code into
  Kitchen::SSH and Kitchen::Provider::Chef, this class found itself
  without a purpose.
Introduce Kitchen::Provider::ChefBase for common Chef provisioner code.
Use ssh_args for test_ssh.
Add support for nodes.

Assuming a directory of `test/integration/nodes/` containing JSON files,
these will be added to the provisioner's sandbox for transfer to the
instance.

Note that this behavior is identical to data bags and roles in that a
suite-specific `nodes/` directory will be used if it exists. For
example, given a suite name of `client` the directory
`test/integration/client/nodes/` will be used for the provisioner's
sandbox.
Add `provisioner` support to .kitchen.yml and default to `"chef_solo"`.

For example:

    ---
    provisioner: chef_solo

    platforms:
      - name: ubuntu-10.04
        provisioner: chef_solo
        driver_plugin: vagrant
        driver_config:
          ...
Add Driver and Provisioner columns to `kitchen list` output.
Initial Chef Zero provisioner: use chef-client on your instances!

This is a first-pass implementation of a chef-client provisioning mode
using Chef Zero, a tiny API-complete implementation of a Chef Server.
The strategy this provisioner uses is the following:

1. Install Chef Omnibus package
2. Create a local sandbox of all Chef data, same as chef_solo except for
   the addition of a client.rb and the chef-client-zero.rb shim binary
3. Install the chef-zero and knife-essentials gems into the Omnibus Ruby
4. Run the chef-client-zero.rb binary which provides all normal
   configuration availble to chef-client

The chef-client-zero.rb shim starts up a Chef Zero server instance
running in the background, overrides some basic configuration (such as
chef_server_url, client_key, and validation_key), creates a chef-client
application and runs it. At the end of the chef-client run the Chef Zero
server will be stopped.
Escape Chef Omnibus install script commands with bash -c '...'.
KITCHEN-75 - support cross suite helpers.

- If there is a test/integration/helpers directory then copy the contents of the test framework specific sub folder
  to the remote suite dir.

For example,

  test/integration/helpers/serverspec/spec_helper.rb

would be copied to /opt/busser/suites/serverspec/spec_helper.rb

This allows common files used across suites (such as spec_helper) to live in one place.
Fixes bundler ref for 1.0.
make init generator safe to run when given an explicit :destination_root
require a safe_yaml release with correct permissions. Fixes #137
Suite run_list is no longer required.

This helps pave the way for non-Chef suites and allows for more
permissive workflows and setups.
Merge pull request #136 from patcon/patch-1

Fixes bundler ref for 1.0.
Update chef-client-zero.rb for knife-essentials 1.2+.
Add Chef and Puppet support to Instance, Suite, & Platform objects.

In this new implementation, the Config class still prepares and
constructs the Instance, Suite, & Platform objects. However, depending
on the provisioner requested, the 3 objects will be extended to be
"Cheflike" or "Puppetlike" so that they can expose methods such as
`#run_list` or `#manifest`.

The Instance, Suite, & Platform extended behavior is determined as
follows:

* If the provisioner name begins with `"chef_"`, then extend the object
  with the appropriate Cheflike module
* If the provisioner name begins with `"puppet_"` then extend the object
  with the appropriate Puppetlike module
* Otherwise do not extend the object

While admitedly, the implemenation is a bit "out of the box", the end
result is the method API contract on Instance, Suite, & Platform are not
altered (assuming we are dealing with a Chef provisioner) and additional
provisioner family types such as Puppet are supportable.
Add documentation to modules containing methods (new Cane rule).
Fixes #151
Setting :on_black when your default terminal text color is black results in unreadable (black on black) text.
Merge pull request #152 from opscode/new-vm-bucket

Fixes #151 - Update the bucket name for Opscode's Bento Boxes