Feature request: ordered instance-type capacity fallback for on-demand builds

## Summary

Add an optional, ordered `instance_types` list to the shared run config so an
`amazon-ebs` (and `ebsvolume` / `ebssurrogate` / `instance`) build can fall
through to an equivalent instance type when the primary type returns an
insufficient-capacity error at launch. This mirrors an EC2 Auto Scaling group's
mixed-instances "prioritized" allocation, but for a single Packer build
instance.

## Problem

A build pinned to a single `instance_type` fails hard with
`InsufficientInstanceCapacity` / `InsufficientHostCapacity` when that type is
capacity-starved, even when an equivalent type would launch immediately. This is
a recurring pain for capacity-constrained families: EC2 Mac Dedicated Hosts,
some GPU/metal families, etc.

### Concrete motivating case

macOS `arm64_mac` AMI builds launch on `mac2.metal` (Apple M1) via
`tenancy=host` into a License Manager host resource group. M1 Dedicated Host
capacity is intermittently exhausted, but the same `arm64_mac` AMI is
cross-compatible with `mac2-m2.metal` (M2) and `mac-m4.metal` (M4). Today the
build simply fails when M1 hosts are full; we want it to try, in cost order:

```hcl
instance_types = ["mac2.metal", "mac2-m2.metal", "mac-m4.metal"]
```

## Proposed design

- Keep `instance_type` (string) exactly as-is (fully backward compatible).
- Add optional `instance_types` (`[]string`), used **in place of**
`instance_type`; mutually exclusive with both `instance_type` and
`spot_instance_types` (mirrors the existing `instance_type` /
`spot_instance_types` rule). This matches the existing precedent of the
ordered `spot_instance_types` list on the Spot path.
- On launch, try each type in order. Fall through to the next **only** on
genuine capacity errors — `InsufficientInstanceCapacity`,
`InsufficientHostCapacity`, `InsufficientReservedInstanceCapacity`. Any other
error (config/permission/quota, e.g. `AuthFailure`, `InstanceLimitExceeded`,
`Unsupported`, `InvalidParameterValue`) fails the build immediately.
- All other placement config (tenancy, `placement.host_resource_group_arn`,
subnet/AZ, license specifications, block device mappings) is type-independent
and reused across attempts.
- Scope: on-demand launch path only; Spot already has `spot_instance_types`.

## Questions for maintainers

1. Field name/shape: `instance_types []string` (proposed) vs an
`instance_type_fallbacks` supplement to `instance_type`?
2. Capacity error-code set — is including
`InsufficientReservedInstanceCapacity` desirable, or keep it to the two
`Insufficient{Instance,Host}Capacity` codes?
3. Burstable (T-family) types are proposed to be rejected in `instance_types`
because the credit specification is derived from `instance_type` (empty when
the list is used) — reasonable, or would you prefer per-candidate credit
derivation instead?

I have an implementation ready (unit-tested, HCL2 spec + docs regenerated) and
am happy to open a PR — filing this first to confirm you're open to the feature
and the shape.

Start with the shared run config and on-demand launch path described in the issue, then inspect the existing spot_instance_types implementation and its unit tests. Confirm the HCL2 spec and regenerated documentation paths, and consider the listed capacity-error and mutual-exclusion questions resolved before treating the feature as done.

Written by the indexing model from the issue text.