feat(networking): route provider authentication through static NAT egress

[Alae-Tamouh]

Issue #, if available:
Relates partially to #398

Description of changes:
Related to #398, which proposes optional advanced security features including VPC placement for all Lambda functions. This PR implements the narrower static provider-egress use case as we require stable egress IP addresses for allow-listing on GitHub organizations and other providers.

This change:

• attaches the GitHub, GitLab, Bitbucket, and credential-broker Lambdas to the existing private subnets and Lambda security group;
• grants their custom execution roles the permissions required for VPC access;
• routes their outbound traffic through the existing NAT gateways;
• exposes the NAT gateway public IP addresses as a Terraform output for allow-listing.

This introduces a NAT dependency for these Lambdas, with corresponding NAT cost
and potential cold-start latency. It does not attempt the broader all-Lambda VPC
placement proposed by #398.

This contribution can be treated independently or closed in favor of a broader implementation of #398 if that direction is preferred.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[jeromevdl]

Thank you, @Alae-Tamouh, for your contribution. This clearly adds value for enterprises with network allowlisting requirements.

We plan to address the broader scope of #398 later, but this is a good first step. However, I would prefer this behavior to be optional, since routing external traffic through the NAT gateway may incur additional costs.

Could we introduce a lambda_vpc_scope variable with these values?

• required (default): Only Lambdas requiring access to private VPC resources, currently primarily Neptune.
• public-egress: required plus all Lambdas accessing non-AWS public services, such as GitHub, GitLab, Bitbucket, and Jira. Ideally, this should also include seed-blocks, since it accesses codeload.github.com, even though that endpoint does not require IP allowlisting.
• all: To be introduced later as part of [Feature]: Offer optional advanced security features #398, placing every Lambda in the VPC.

If you don't have the bandwidth to address this, let me know and we'll take over. Thanks again.

[Alae-Tamouh]

Thanks for the suggestion @jeromevdl, it makes sense to have this feature as an option, as not all users are gated behind enterprise allow-lists.
I implemented the lambda_vpc_scope with the two values as suggested.
I will let you handle the all value and additional security features in the dedicated feature #398.