(cdk): Ability to create a Docker volume

### Describe the feature

The CDK currently provides [DockerVolume](https://docs.aws.amazon.com/cdk/api/v2/python/aws_cdk/DockerVolume.html), provides us the ability to create a [bind mount](https://docs.docker.com/storage/bind-mounts/), exposing a file or directory on the host to Docker, in my scenario to a Docker based Lamdba build.

However Docker also provides [volumes](https://docs.docker.com/storage/volumes/), which are completely managed by Docker, and independent of the host OS and file system. For any build scenario where there's value in caching assets, a Docker volume is going to be a better, more robust, and more platform independent option than a bind mount.

### Use Case

I'm using Gradle to manage builds for my Java Lambdas. I'd like to be able to provide a persistent volume to the Docker based build as /root/.gradle that each build can cache information to, for use by future builds.

I've tried doing this using [DockerVolume](https://docs.aws.amazon.com/cdk/api/v2/python/aws_cdk/DockerVolume.html), which as I understand Docker terminology actually provides us the ability to create a [bind mount](https://docs.docker.com/storage/bind-mounts/). The problem I face is the Java 11 bundling image, like most Docker images, runs as root.

So if I try using a bind mount the files written back to the host operating system are owned by root. Having files written to user home directories that are owned by root is a surprising and bad side effect of running a cdk build. And having a build write files to subdirectories of /root also seems surprising and wrong.

Being able to use a Docker named volume is the perfect solution to this caching issue, and any other scenario where caching might be wanted across multiple Docker based builds.

### Proposed Solution

It's kind of messy, because the name `DockerVolume` is already being used for a Bind Mount. Otherwise I'd suggest a new class called `DockerVolume`.

However as DockerVolume is already defined, I think the cleanest thing would be for the `DockerVolume` constructor to provide a new parameter, `volume_name`. `host_path` and `volume_name` would be mutually exclusive. If you provide `host_path`, you get the existing behavior where you get a bind mount. If you provide `volume_name`, you get a named volume mounted, using the Docker default options.

Docker volumes have a lot of options this suggestion doesn't expose. However once this is implemented, it would be an simple extension to then allow setting of those options, possibly by exposing a `volume_options` parameter on the `DockerVolume` constructor.

### Other Information

_No response_

### Acknowledgements

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

### CDK version used

2.26.0

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

Ubuntu 20.04 on WSL 2 within Windows 10.0.19044

Start with the existing DockerVolume API linked in the issue and compare its bind-mount behavior with Docker's named-volume documentation. Define how mutually exclusive host_path and volume_name should be represented, then verify that named volumes can persist across Docker-based builds without writing cached files to the host filesystem.

Written by the indexing model from the issue text.