(ecs): introduce IContainerImage interface for custom container image providers

### Describe the feature

The `ContainerDefinitionOptions.image` property currently accepts only the abstract `ContainerImage` class, which limits extensibility for custom container image providers. Users who need custom implementations (e.g., integration with private registries, dynamic image selection, or custom authentication) must extend the abstract class, which is cumbersome and prevents easy external package distribution.

Introducing an `IContainerImage` interface would enable users and third-party library authors to provide custom container image implementations without extending the abstract class, following the Open/Extensible principle of CDK.

### Use Case

**Enterprise Custom Registry Integration**

Organizations using private container registries (JFrog Artifactory, Harbor, GitLab Registry, etc.) need custom authentication and image resolution logic:

```typescript
// Currently required: must extend abstract class
class ArtifactoryImage extends ecs.ContainerImage {
constructor(private registry: string, private image: string) {
super(); // Required but adds no value
}

public bind(scope: Construct, containerDefinition: ecs.ContainerDefinition) {
const credentials = this.getCredentialsFromVault();
return {
imageName: `${this.registry}/${this.image}`,
repositoryCredentials: { credentialsParameter: credentials },
};
}
}
```

### Proposed Solution

Introduce an IContainerImage interface and update the type signature
```ts
/**
* Interface for container image providers.
*/
export interface IContainerImage {
/**
* Called when the image is used by a ContainerDefinition.
*/
bind(scope: Construct, containerDefinition: ContainerDefinition): ContainerImageConfig;
}

/**
* Constructs for types of container images
*/
export abstract class ContainerImage implements IContainerImage {
// Existing static factory methods and implementation unchanged
}

// Update the property type
export interface ContainerDefinitionOptions {
readonly image: IContainerImage; // Changed from: ContainerImage
// ...
}

```

### Other Information

_No response_

### 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.x

### AWS CDK CLI version

2.x

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

all

Start by tracing ContainerDefinitionOptions.image and the existing ContainerImage.bind contract in the TypeScript ECS implementation. Check how ContainerImageConfig and ContainerDefinition are exposed, then verify that external implementations can satisfy IContainerImage while existing ContainerImage factories remain unchanged. Done means custom providers work without subclassing the abstract class.

Written by the indexing model from the issue text.