Add Software Supply Chain Functionality to `supplychain` subcommand

### Describe the feature

## Feature Description

This feature request proposes adding a new `supplychain` subcommand to the AWS CLI that provides comprehensive software supply chain security and management capabilities. The subcommand would enable developers and security teams to interact with AWS services related to software composition analysis, vulnerability management, and supply chain attestation directly from the command line.

### Core Functionality

The `aws supplychain` subcommand would provide:

- **SBOM Management**: Generate, upload, retrieve, and analyze Software Bill of Materials (SBOM) in standard formats (SPDX, CycloneDX)
- **Vulnerability Scanning**: Scan container images, Lambda functions, and application dependencies for known vulnerabilities
- **Attestation & Provenance**: Create and verify cryptographic attestations for build artifacts, track provenance data, and ensure artifact integrity
- **Dependency Analysis**: Analyze direct and transitive dependencies, identify outdated packages, and detect license compliance issues
- **Policy Enforcement**: Define and enforce supply chain security policies, with automated compliance checks
- **Integration Points**: Seamless integration with AWS services like ECR, CodeArtifact, Inspector, Signer, and Systems Manager

### Use Case

### Use Case

Organizations increasingly need to secure their software supply chains to meet regulatory requirements, prevent supply chain attacks, and maintain visibility into their software composition. Currently, managing these aspects across AWS services requires multiple tools and manual processes.

**Key scenarios this feature addresses:**

1. **DevSecOps Teams** need to automatically generate and store SBOMs for all container images pushed to ECR, then query these SBOMs to identify which applications contain specific vulnerable dependencies

2. **Compliance Officers** must demonstrate software provenance and maintain an audit trail of all components used in production systems to meet regulatory requirements (EU CRA, US Executive Order 14028)

3. **Security Engineers** want to quickly identify all workloads affected by a newly discovered vulnerability across their entire AWS infrastructure

4. **Platform Teams** need to enforce policies that prevent deployment of artifacts without proper attestations or with critical vulnerabilities

### Example Commands
```bash
# Generate and upload SBOM for a container image
aws supplychain generate-sbom --image-uri $ECR_IMAGE --format spdx --upload

# Check for vulnerabilities in dependencies
aws supplychain scan --resource-arn $LAMBDA_ARN --severity CRITICAL,HIGH

# Create attestation for build artifact
aws supplychain attest --artifact-uri s3://bucket/artifact.zip --predicate-type slsa-provenance

# Query all resources using a specific vulnerable package
aws supplychain query --package "log4j" --version "<2.17.0" --region us-east-1

# Enforce supply chain policy
aws supplychain apply-policy --policy-file security-policy.yaml --enforcement-mode BLOCK

### Proposed Solution

_No response_

### Other Information

## Proposed Solution

### Architecture Overview

The `aws supplychain` subcommand would be implemented as a composite service client that orchestrates multiple AWS services through a unified interface. It would leverage existing AWS SDKs and APIs while providing higher-level abstractions for common supply chain security workflows.

### Implementation Approach

#### 1. **Service Integration Layer**
Create a new service client module that interfaces with:
- **Amazon Inspector** - For vulnerability scanning and SBOM generation from container images
- **AWS Signer** - For artifact signing and attestation verification
- **Amazon ECR** - For container image metadata and scan results
- **AWS Systems Manager Inventory** - For tracking software components across EC2 instances
- **Amazon CodeArtifact** - For package dependency analysis
- **AWS Lambda** - For function metadata and layer inspection
- **Amazon S3** - For SBOM storage and artifact management
- **AWS IAM** - For policy enforcement and access control

#### 2. **Command Structure**
```
aws supplychain
├── generate-sbom # Create SBOMs from various sources
├── scan # Perform vulnerability scanning
├── attest # Create/verify attestations
├── query # Search across supply chain data
├── policy # Manage supply chain policies
├── inventory # List and track components
└── report # Generate compliance reports
```

#### 3. **Data Model & Storage**

**Centralized Metadata Store**: Utilize Amazon DynamoDB or Amazon Neptune to maintain:
- SBOM registry with versioning
- Vulnerability correlation data
- Attestation chains
- Policy definitions
- Component dependency graphs

**Schema Example**:
```json
{
"resourceArn": "arn:aws:ecr:us-east-1:123456789:repository/app:v1.0",
"sbom": {
"format": "spdx-2.3",
"location": "s3://supply-chain-bucket/sboms/app-v1.0.spdx.json",
"generated": "2024-01-15T10:00:00Z",
"components": 247
},
"attestations": [
{
"type": "slsa-provenance-v1",
"signature": "...",
"timestamp": "2024-01-15T09:30:00Z"
}
],
"vulnerabilities": {
"critical": 0,
"high": 2,
"medium": 5,
"lastScanned": "2024-01-15T10:05:00Z"
}
}
```

#### 4. **Plugin Architecture**
Implement an extensible plugin system to support:

- **Format Plugins**: Handle different SBOM formats (SPDX, CycloneDX, SWID)
- **Scanner Plugins**: Integrate various vulnerability databases (NVD, OSV, GHSA)
- **Attestation Plugins**: Support multiple attestation frameworks (SLSA, in-toto, Sigstore)
- **Policy Plugins**: Enable custom policy engines (OPA, Cedar)

### Acknowledgements

- [x] I may be able to implement this feature request
- [ ] This feature might incur a breaking change

### CLI version used

2.28.26

### Environment details (OS name and version, etc.)

macOS, Linux