Improve tests of constructs

Now that we finally having deployment tests that work, here are ideas to improve them.

- For now we're essentially just testing that we're writing proper CDK code that produces cloud formation templates that we can use to deploy-destroy without bugs. We're not testing any of the deployed applications (initially I had planned to include that, i.e ingest some test metadata and test usage of the STAC api, the raster API, etc, but other challenges piled up and I wanted to get something out of the door so I simplified the tests to just a deploy-destroy process). Should we add actual tests of the apps at some point ? Ideally it shouldn't contain too much application logic (these tests should live in the actual app repositories, titiler-pgstac, etc). Maybe simple checks that the APIs are reachable ?

- We only have one test case that's quite specific : no STAC ingestor, STAC browser or bastion host, the DB is in a public subnet and allows connections from any IP (only barrier is the password), application lambdas are not placed in VPCs. Should we add different configuration cases in the test deployments ?

- Now that I am writing about this, I am thinking there _must_ be some framework we can reuse for doing real world testing of our constructs, since there are a lot of constructs being developed out there. Just stumbled upon [this](https://docs.aws.amazon.com/cdk/api/v2/docs/integ-tests-alpha-readme.html), not sure if it does what we want. I think it's meant to be use with this CLI tool https://github.com/aws/aws-cdk/tree/main/packages/%40aws-cdk/integ-runner developed by AWS for their own constructs repository, which essentially does what we're doing (try to synth, deploy and destroy templates resulting from constructs) but in a more fancy way.

Start by reviewing the existing deployment tests and their current deploy-destroy scenario. Compare that approach with AWS CDK's integ-tests-alpha documentation and the linked integ-runner entry point, then determine whether they support testing deployed application reachability and additional construct configurations. Done should include a decided testing scope and documented cases or framework changes.

Written by the indexing model from the issue text.