full snapstart and provisioned concurrency support

[dfuentes77]

Description

Hoping to support Snapstart and Provisioned Concurrency while using aliases, since they are required.

This also allows the deployments to be more blue/green by having ALB and api-gateway point to aliases and only migrating an alias when newly deployed lambda is "ready"

New tests added. All tests pass locally.

GitHub Issues

#1463

[monkut]

Took a look at this along with #1463 — the issue is real. On master we publish versions for SnapStart, but API Gateway still points at the unqualified ARN, so everything invokes $LATEST and the snapshots never actually get used. The alias approach here is the right fix.

I checked out the branch and ran the test suite locally — all green (the few failures I hit were just my machine running out of disk, they fail on master too). With none of the new settings configured the generated templates and Lambda calls are unchanged, so existing deployments aren't affected.

CI is only failing on black --check — running make black should sort it out. The actual test jobs never ran.

A few things I noticed:

• One that I think is worth addressing in this PR: on zappa update, the provisioned-concurrency version gets published (and the alias moved to it) before the config update lands on $LATEST. Since a published version freezes code + config together, env var / memory / timeout changes won't reach alias-routed traffic until the next update. That's likely to confuse people — you change an env var, run zappa update, the deploy succeeds, but live traffic still sees the old value with no indication why. Proposed fix: move the provisioned-concurrency handling (publish, put_provisioned_concurrency_config, wait for READY, migrate alias, clean up the old version's config) out of update_lambda_function and into update_lambda_configuration, after the config change is applied — i.e. the same ordering the SnapStart path already uses. Then the published version captures both the new code and the new config in one deploy.
  And two smaller ones, not blockers:

• With a very low num_retained_versions (like 1), version pruning can try to delete the version the snapstart alias still points to and blow up with ResourceConflictException. The default of 5 is fine, but maybe worth a guard or a doc note.

• zappa rollback republishes old code but doesn't move the aliases, so traffic won't actually roll back for SnapStart/provisioned-concurrency users. The ALB alias has the same gap today, so fine as a follow-up.