Native Lambda runtimes instead of custom containers

Hi and thanks for the repo!

From skimming through it looks like nearly/all the `lambda/` functions in this library are using custom containers rather than plain zip file architecture, but the ones I saw also didn't seem to have any particular reason for doing that over using [`@aws-cdk/aws-lambda-python-alpha/PythonFunction`](https://docs.aws.amazon.com/cdk/api/v2/docs/@aws-cdk_aws-lambda-python-alpha.PythonFunction.html)?

The `PythonFunction` construct still runs Python install commands in a Lambda-compatible Docker image locally (to avoid build vs deployment compatibility issues with libraries that include native components), but packages the result as a standard zip-based function.

As I understand, the `DockerImageFunction` construct used here builds the image locally and then packages it to Amazon ECR - defining a container-based function in Lambda.

If there are no particular complex build requirements, it seems like using native zip function runtimes could deliver some benefits? E.g:
- Avoiding ECR cost and clutter (permissions, management, etc)
- Possibly a little less boilerplate (Dockerfiles vs requirements.txt/pyproject.toml)
- I have no data to support it, but seems logical to me that if there *were* any cold-start performance difference between the two approaches, then pulling a customer-specific container image might be trickier than a native platform runtime?

...But maybe I'm missing some reason containerized functions are useful here?

Start by reviewing the functions under lambda/ and tracing where DockerImageFunction and PythonFunction are configured. Compare the current container build requirements with the native zip approach, then establish whether the project should migrate the functions or document why containers remain necessary.

Written by the indexing model from the issue text.