Reduce `NextjsGlobalFunctions` Dynamic Page Cold Start

Cold start on `NextjsGlobalFunctions` Dynamic Page is ~1.82s while warm start is ~.29s
```
curl -o /dev/null -s -w 'Establish Connection: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' https://d17p57hi2bzun3.cloudfront.net/ssr/1
Establish Connection: 0.107531s
TTFB: 1.812416s
Total: 1.824499s
curl -o /dev/null -s -w 'Establish Connection: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' https://d17p57hi2bzun3.cloudfront.net/ssr/1
Establish Connection: 0.022148s
TTFB: 0.247286s
Total: 0.286576s
```
Based on [The case for containers on Lambda (with benchmarks)](https://aaronstuyvenberg.com/posts/containers-on-lambda), container image size strongly correlates with cold start time so reducing the size of our container image is of utmost important. Currently the examples/global-functions app using the Next.js App Router Playground app container image is 78.53MB on ECR. Based on benchmarks in the blog, we should be able to get this down to ~1.33s if we can hit 50MB.

Two ideas I have for reducing container image size are

1. Using `du -sh */` to explore container and find unnecessary files we can delete.
2. Offload some node_modules (especially sharp binaries) to EFS so that they don't drag down lambda cold start. We'll have to symlink into EFS but that's a tried and true pattern. In order to do this, prefixing EFS directories with Next.js current build id / deployment id is critical b/c we don't want deployment B's new sharp version's binary to impact the current deployment A's running function. Beyond sharp, we might be able to do this for Next.js which I think its next biggest. Sharp's binary is 15MB so that's large savings.

Curious to hear if other's have ideas for how to speed up cold start!