aws-fsx: add L2 construct for FSx for NetApp ONTAP file system, storage virtual machine, and volume

### Describe the feature

The `aws-fsx` module currently only provides an L2 construct for FSx for Lustre. This request is for full L2 construct coverage for FSx for NetApp ONTAP, including:

1. `OntapFileSystem` supporting all four deployment types (MULTI_AZ_1, MULTI_AZ_2, SINGLE_AZ_1, SINGLE_AZ_2), throughput capacity configuration, automatic backup, disk IOPS provisioning, multi HA pair scale out, customer managed KMS, and endpoint IP range configuration.

2. `OntapStorageVirtualMachine` supporting optional Active Directory integration (inline credentials or Secrets Manager backed) and root volume security style configuration.

3. `OntapVolume` supporting junction paths, storage efficiency, tiering policies, FlexVol/FlexGroup volume styles with aggregate configuration, SnapLock (Compliance and Enterprise), DP (data protection) volumes, and restore from backup.

4. `OntapFileSystemSecret` as an optional convenience helper that generates a Secrets Manager secret with a strong password that excludes the characters FSx for ONTAP forbids in admin passwords.

The constructs should provide comprehensive synth time validation against AWS constraints and fail fast with descriptive errors instead of waiting for deploy time failures.

### Use Case

When provisioning FSx for NetApp ONTAP resources with CDK, the only option today is to use the L1 CfnFileSystem, CfnStorageVirtualMachine, and CfnVolume constructs directly. This requires deep CloudFormation knowledge, offers no input validation, no type safety for throughput or deployment type combinations, and no developer convenience.

Many configurations only fail at deploy time with opaque error messages (for example, invalid throughput/deployment type combinations, wrong subnet count for Multi AZ, or forbidden characters in volume names). Having these caught at synthesis would save significant iteration time.

The Lustre file system already has an L2 in the same module, so the gap for ONTAP means users have two very different authoring experiences within the same `aws-fsx` package.

### Proposed Solution

Add three new L2 constructs (`OntapFileSystem`, `OntapStorageVirtualMachine`, `OntapVolume`) plus an optional `OntapFileSystemSecret` helper to the `aws-fsx` module. Key design points:

1. Type safe throughput capacity via `ThroughputCapacityPerHaPair` that exposes discrete valid values per deployment type as static members, cross validated at synth.

2. Synth time validation for storage capacity ranges, IOPS limits, subnet requirements for Multi AZ vs Single AZ, FlexGroup vs FlexVol coupling, SnapLock retention ordering, junction path format, volume name rules, etc. All skip validation gracefully for CDK tokens.

3. `RemovalPolicy.RETAIN` by default on all three resource types since they are stateful and we should never silently destroy customer data.

4. Plain text secret warning annotations when admin passwords are supplied as literal values recommending Secrets Manager backed values instead.

5. Import methods (`fromOntapFileSystemAttributes`) for referencing existing resources.

### Other Information

This feature request is tracked by PR [](https://github.com/aws/aws-cdk/pull/38061) which provides the full implementation with more than 300 unit tests, 5 integration tests covering all major deployment types, and complete README documentation including a Common Pitfalls section.

The implementation mirrors the patterns established by the existing `LustreFileSystem` construct in the same module and follows the CDK Design Guidelines.

### Acknowledgements

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

### AWS CDK Library version (aws-cdk-lib)

2.259.0

### AWS CDK CLI version

2.1126.0 (build a90d578)

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

Amazon Linux 2 (kernel 5.10.257, x86_64), Node.js v18.20.8, TypeScript 5.9.3

Start by reviewing the existing LustreFileSystem construct in the aws-fsx module and PR #38061, which contains the proposed implementation. Check its more than 300 unit tests, five integration tests, README documentation, and Common Pitfalls section; the work is done when the three ONTAP constructs and optional secret helper provide the stated validations and coverage.

Written by the indexing model from the issue text.