Native EBS Snapshot Asset Handling

## Description

Upload raw disk images as EBS snapshots using the [EBS direct APIs](https://docs.aws.amazon.com/ebs/latest/APIReference).

Note that this requires the `AWS::EC2::Image` CloudFormation resource proposed in https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/2175 to let users create an AMI from this EBS snapshot.

### Background

The [EBS direct APIs](https://docs.aws.amazon.com/ebs/latest/APIReference) let users create EBS snapshots by uploading a block device directly to EBS.

This is significantly faster compared to [`ec2:ImportSnapshot`](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ImportSnapshot) which requires users to upload a disk image to S3 first.

Use cases include:

- Creating NixOS AMIs from NixOS raw disk images produced by the [NixOS systemd-repart helper](https://nixos.org/manual/nixos/stable#sec-image-repart).
- Useful for the [AWS official NitroTPM examples for attestable NixOS AMIs](https://github.com/aws/nitrotpm-attestation-samples/tree/main/nix) (cc: @agraf @iorlov-dev @mariusknaust).
- Creating Linux AMIs from raw disk images produced by [mkosi](https://github.com/systemd/mkosi).
- Creating macOS AMIs from raw disk images produced by `diskutil` + `hdiutil`.
- Creating Windows AMIs from raw disk images produced by QEMU and converted with [qemu-img](https://www.mankier.com/1/qemu-img).

### Proposal

Introduce a new `aws_ebs_assets` module with an `aws_ebs_assets.SnapshotAsset` class. Example usage should look like this (assuming the proposed `AWS::EC2::Image` CloudFormation resource exists):

```typescript
import { SnapshotAsset } from 'aws-cdk-lib/aws-ebs-assets';
import { CfnImage } from 'aws-cdk-lib/aws-ec2';

// Create an EBS snapshot.
const asset = new SnapshotAsset(this, 'MySnapshot', {
path: 'path/to/local/raw/disk/image',
});

// Create an AMI.
const ami = new CfnImage(this, 'MyImage', {
source: {
register: {
architecture: 'arm64',
bootMode: 'uefi',
blockDeviceMappings: [
{
ebs: {
snapshotId: asset.snapshotId,
},
},
],
},
},
});
```

Note that we can't control the snapshot name so if we want to store the asset hash for deduplication like with S3 assets, it must be in the snapshot descripton or tags.

## Roles

| Role | User
|---------------------|------------------------------
| Proposed by | @commiterate
| Author(s) | _Pending_
| API Bar Raiser | _Pending_
| Stakeholders | _Pending_

> See [RFC Process](https://github.com/aws/aws-cdk-rfcs#rfc-process) for details

## Workflow

- [x] Tracking issue created (label: `status/proposed`)
- [ ] API bar raiser assigned (ping us at [#aws-cdk-rfcs](https://cdk-dev.slack.com/archives/C025ZFGMUCD) if needed)
- [ ] Kick off meeting
- [ ] RFC pull request submitted (label: `status/review`)
- [ ] Community reach out (via Slack and/or Twitter)
- [ ] API signed-off (label `status/api-approved` applied to pull request)
- [ ] Final comments period (label: `status/final-comments-period`)
- [ ] Approved and merged (label: `status/approved`)
- [ ] Execution plan submitted (label: `status/planning`)
- [ ] Plan approved and merged (label: `status/implementing`)
- [ ] Implementation complete (label: `status/done`)

---

> Author is responsible to progress the RFC according to this checklist, and
apply the relevant labels to this issue so that the RFC table in README gets
updated.

No implementation files or tests are named. Start by reading the linked EBS direct APIs and the RFC Process, then review the proposed SnapshotAsset API and its CloudFormation integration; done means the RFC has assigned roles, completed review, and reached an approved execution plan.

Written by the indexing model from the issue text.