Configurable timeouts and cancellation-aware polling

Problem

All lifecycle waits are hard-coded to 30 seconds with no config knob: instance start (step_instance_create.go), instance stop (step_instance_stop.go), and every cleanup call (context.TODO() + 30s). 30s to stop an instance that just ran provisioners is optimistic, and users have no way to raise it. Other plugins expose a state_timeout-style option (e.g., DigitalOcean).

Related robustness issues in the same code:

• Wait loops check ctx only at the top of the loop, then time.Sleep(3 * time.Second) unconditionally — Ctrl-C waits out the sleep. Should select on ctx.Done() vs a timer.
• stepInstanceStop halts on the first transient InstanceView error mid-poll, while the cleanup path retries the same call — the run path should be at least as tolerant as cleanup.
• The data source's Execute uses context.TODO() with no timeout; a hung API call hangs packer build indefinitely.

Fix

• Add config options for state timeouts (and possibly poll interval), threaded into all wait loops and cleanup contexts.
• Make polling cancellation-aware.
• Retry transient errors in wait loops consistently.

Start with step_instance_create.go and step_instance_stop.go, then trace the cleanup calls and the data source Execute that use context.TODO() and 30-second waits. Review each polling loop and its transient-error handling before deciding how state timeouts and cancellation should be threaded through. Done means lifecycle waits and cleanup honor configured timeouts, polling responds to cancellation, and transient errors are handled consistently.