Support Compute Blue/Green Deployments

Blue/Green Deployments are a best practice as shown [here](https://docs.aws.amazon.com/whitepapers/latest/blue-green-deployments/welcome.html). CDK Next.js's deployment/update process is currently not compatible with blue/green because updates are not reversible. During deployment/update process, static assets are written to S3 on top of the previous objects and same for EFS. For EFS, we can make the deployment blue/green compatible by creating a new directory within EFS on each deployment named using Next.js Build ID such that old lambda functions or fargate containers can continue to read from current EFS directory and new lambda functions or fargate containers can read from new directory and traffic is slowly switched. For S3, we can use the S3 CloudFront Origin Path attribute as the Next.js Build ID to partition old and new.

This will all take coordination in `NextjsAssetsDeployment` to write to correct path in file system and bucket (but easy to do because it's just changing CR resource props). We'll have to extract Next.js Build ID from the nextjs build container to pass to `NextjsAssetsDeployment`.

This construct requires `/health` route to be defined, so we can use that to test whether or not green deployment is ready to accept traffic. Users will likely want to setup more sophisticated checks that are app specific and we'll document how to do that but by defaul we'll just do basic health check. How quickly should we shift traffic over? Should this construct be opinionated about that? Doesn't ECS already do B/G deployments with [circuit breaker](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-circuit-breaker.html)? Anything more need to be done there? For lambda do we need to setup versions/aliases?

After successful deployment, how do we clean up unneeded s3 object and EFS files? I want to propose changing: `NextjsInvalidation` to `NextjsPostDeployment` which will do CloudFront invalidation but also prune/delete old s3 objects and EFS files. It's critical this waits to run until successful deployment. We don't want deployment to take forever, so this makes me think we want to try to quickly shift traffic from blue to green.

How do we provide skew protection? What happens when user opens tab, interacts with web app, then goes away, new deployment is created and runs changing the static asset names that are available in S3/CloudFront. Then when user comes back to web app their html page will have references to old static assets that will return 404s. That's skew. How do we protect? Vercel has [skew protection](https://vercel.com/docs/deployments/skew-protection?utm_source=next-site&utm_medium=docs&utm_campaign=next-website) BUT it says on [Next.js docs](https://nextjs.org/docs/pages/building-your-application/deploying#version-skew) that:
> Next.js will automatically mitigate most instances of [version skew](https://www.industrialempathy.com/posts/version-skew/) and automatically reload the application to retrieve new assets when detected.

Does framework just automatically handle that for us? How? Doesn't it have to send deployment id in each request? I'm not seeing that.

Start by reading the NextjsAssetsDeployment and NextjsInvalidation constructs and the Next.js build container flow. The issue requires design decisions for build-ID partitioning, health checks, traffic shifting, cleanup, and skew protection; done would be a coordinated reversible deployment with documented behavior, but no tests or concrete entry points are named.

Written by the indexing model from the issue text.