Update the testing infrastructure: test-kitchen, strainer

Dear automation-loving Ceph users,

let's test our cookbooks more thoroughly.  For quick testing of recipe/distribution combinations, [test-kitchen](http://kitchen.ci) is incredibly handy.  For example, testing a PR like #81, you could just `kitchen converge repo-centus-64` to spin up a CentOS vagrant box, put Chef, the cookbook and its dependencies there, and initiate a chef-solo run.
A next step here would be to include tests that are done _after_ a successful converge run, e.g. "is the service really started on CentOS"?  There are [various options](https://rubygems.org/search?utf8=%E2%9C%93&amp;query=busser-) that can easily be used within the test-kitchen framework.

Beside that, I added a [Strainerfile](https://github.com/customink/strainer) for isolated cookbook tests, i.e. you would run `bundle install && bundle exec strainer test` to have a kind of unit test for the cookbook.  The next step here would be to use [ChefSpec](http://code.sethvargo.com/chefspec/) to spec and test the various recipes.

Putting both things together, test-kitchen should allow us to quickly address for example the various [foodcritic criticisms](https://gist.github.com/srenatus/8576088).

What are the general opinions regarding this?  (Is the Ceph cookbook solely a community effort?)

(Btw for some reason, [Strainer still fails on travis-ci](https://travis-ci.org/srenatus/ceph-cookbooks/builds/17466834)... would this break the current CI? I haven't found this cookbook's CI run on the website...)

Thanks for your time (and effort).

Cheers
Stephan