adding /opt/local/bin to search path. smartmachines need this otherwise curl cant find certificates
Fix Windows path matching issues introduced by 1c924af2e9
Allow files in subdirectories in "helpers" directory

Closes #312
Upload chef clients data
Add reference to IRC transcripts in README.
Merge pull request #309 from someara/smartos-curl

adding /opt/local/bin to search path. smartmachines need this otherwise ...
Add TravisCI testing for Ruby 2.1.0.
Merge pull request #310 from rarenerd/fix_yaml_tests

Fix Windows path matching issues introduced by 1c924af2e9
Merge pull request #313 from mthssdrbrg/helpers-directories

Allow files in subdirectories in "helpers" directory
[CLI] Add test for exact match over regex at start of token.

Closes #316
Merge pull request #318 from jtimberman/jtimberman/chef-clients-upload

Upload chef clients data
Stub in a dummy bootstrap if none are found in shell provisioner.

References #335
Kamalika | added exit status check in chef-zero support for chef 10
Pin minitest to ~> 5.1.0 for moment.
Merge pull request #353 from kamalim/master

Kamalika | added exit status check in chef-zero support for chef 10
Release 1.2.0, concurrency, shells, error handling, & more!
Up version for development.
Load needed (dynamic) dependencies for provisioners at creation time.

The need for this change was initated with #293 which runs every
instance action in a thread of execution, even in serial mode. The issue
is that on the Mac platform MRI Ruby 1.9 and 2.0 (not confirmed for
2.1), dynamic (i.e. native) code needs to be loaded in the main thread
otherwise causing a "Trace/BPT trap: 5" crash.

References:

* http://stackoverflow.com/questions/9933969/matlab-ruby-gem-doesnt-work-when-called-from-thread#answer-12319780
* https://bugs.launchpad.net/sbcl/+bug/1014409

For Berkshelf 2.0.x at least, there are multiple transitive dependencies
that *could* load native code, meaning that `require 'berkshelf'` could
very well lead to a VM crash if performed in a thread other than main.

This commit pushes library loading code ahead to Provisioner creation
time. In other words, by the time you have a Provisioner object
reference either Berkshelf, Librarian-Chef, or nothing has been required
(assuming a Chef provisioner).

A drawback to this approach is that these dynamic dependencies will be
eagerly loaded when Test Kitchen is booting for trivial CLI commands
such as `kitchen list` and `kitchen diagnose`. Further work is needed to
ensure that `kitchen diagnose` remains viable even in the face of a
failure to load these dependencies.

Finally, the loaded version of Berkshelf or Librarian-Chef will be
displayed to the user on INFO for converge action and DEBUG on code
loading for troubleshooting.

Closes #357

/cc @reset, @ivey, @sethvargo
Record failures to build instances when running `kitchen diagnose`.

In resolving #357 some code loading logic needed to be moved early in
an object's life meaning that an Instance (or a collaborator object)
could crash before `#diagnose` was callable.

A design goal for `kitchen diagnose` is that it not crash itself and to
provide some minimum useful information in a failure scenario.

This commit will return an error hash in the :instances and :loader keys
if an exception was raised.
On non-expected crashes, tell the user to try `kitchen diagnose --all`.