feat: implement the driver api version, plugin version, status, and doctor hooks

[tas50]

This driver implemented none of the optional plugin hooks. It now implements all four.

kitchen_driver_api_version 2 and plugin_version

kitchen_driver_api_version 2
plugin_version Kitchen::Driver::DIGITALOCEAN_VERSION

kitchen diagnose reported version: nil for the driver before this, so a bug report never said which kitchen-digitalocean produced it.

#status

Asks the API what state the Droplet is actually in, so kitchen list can report it rather than inferring from the state file. Falls back to the base "unknown" answer when there is no Droplet in state, the id is gone, or the API cannot be reached — kitchen list should not raise.

#doctor

Two checks, both reachable:

• the configured access token is rejected by the API
• ssh_key_ids is set but empty, which builds a Droplet with no key installed and a transport that cannot log in

I dropped a third check I had written for a missing access token: required_config :digitalocean_access_token already rejects nil and empty string during finalize_config!, so doctor can never see one. Duplicating it would have been unreachable code that looked like coverage.

One trap worth flagging

The first version of #token_problems used a bare rescue StandardError and caught nothing. Test Kitchen defines its own Kitchen::StandardError < ::StandardError, and inside module Kitchen; module Driver the bare constant resolves lexically to Kitchen::StandardError — so the rescue silently narrows to Test Kitchen's own errors and a real ::StandardError sails straight through.

rescue ::StandardError => e

The leading :: is load bearing. I checked the other twenty kitchen-* repos for the same pattern; none of them have it.

Verification

• rake test — 175 examples, 0 failures (164 before; 11 new)
• cookstyle --chefstyle — 5 files, no offenses
• yard stats — 21 methods, 0 undocumented, 100%