test: verify the plugin works with Test Kitchen in CI

[tas50]

These plugins exist to be run by Test Kitchen, and nothing in CI ever ran them
that way. The cucumber features drive busser directly, which covers the plugin
but skips the whole verifier path -- how Test Kitchen installs busser, installs
the plugin, transfers the suite and invokes it.

This adds a kitchen verify job that runs the real thing:

• driver: exec with transport: exec, both shipped with Test Kitchen, so
  the "machine under test" is the CI runner. No Docker, no VM, no credentials,
  a couple of seconds per run.
• The real busser verifier, pointed at the running Ruby rather than
  Chef's omnibus and told not to sudo for a path inside the workspace.
• kitchen-preinstall.sh puts this working tree into the Busser root first,
  so the job tests the branch rather than the last release from RubyGems.

test/integration/default/ holds a small suite in the plugin's own language.

Two things worth knowing about the setup

It deliberately does not use bundler. No bundler-cache, no bundle exec.
The verifier shells out to gem list to decide what to install, and bundler in
the environment makes that report the bundle's gems rather than the Busser
root's -- so it skips installing busser and the run dies on a path that was
never created. Test Kitchen is not run from inside a project's bundle in real
use either.

The pre-install has to install busser itself and run the postinstall. The
verifier's check is grep "^busser" with no anchor at the end, so a plugin
named busser-* satisfies it and busser would never be installed. And skipping
busser plugin install also skips the plugin's postinstall, which is where a
plugin installs the framework it drives.

Verified both directions locally: a passing suite exits 0, and a deliberately
failing test makes kitchen verify exit 20.

The suite includes a helper.sh, which is not named *_test.sh or *_spec.sh
and so must never run. If the glob ever widens, it fails the suite loudly.