add: Update Security Group conf to allow either CIDR or Existing Security Group Configurations

[brent-anyscale]

This change allows for the use of either CIDR or Existing Security Group configurations for the security group ingress rules. This is useful for customers who have existing security groups they want to use to grant access to the Anyscale data plane.

This also cleans up commented-out code from older releases.

On branch brent/update-security-group-config
Changes to be committed:

• modified: CHANGELOG.md
• modified: README.md
• modified: main.tf
• modified: modules/aws-anyscale-securitygroups/examples/main.tf
• modified: modules/aws-anyscale-securitygroups/examples/outputs.tf
• modified: modules/aws-anyscale-securitygroups/main.tf
• modified: modules/aws-anyscale-securitygroups/variables.tf
• modified: variables.tf

Pull request checklist

Please check if your PR fulfills the following requirements:

• pre-commit has been run
• Tests for the changes have been added (for bug fixes / features)
• All tests passing
• Docs have been reviewed and added / updated if needed (for bug fixes / features)

Pull Request Type

• Bugfix
• New feature
• Refactoring (no functional changes)
• Documentation change
• Other (please describe):

Does this introduce a breaking change?

• Yes
• No

[brent-anyscale]

@RCdeWit if you have some time, can you test upgrading from a previous version to this latest one? I've done a couple of quick tests, but I could use a more thorough approach. I want to ensure that the security group doesn't get rebuilt (and thus generate a new security group ID).

[RCdeWit]

Deploy on main branch:

terraform output | grep security_group_id
anyscale_v2_security_group_id = "sg-012943ff7d6927a55"

Switch to dev branch and deploy again, using the try() from my suggestion above:

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

And the anyscale_v2_security_group_id remains unchanged. But I haven't tested this with an existing security group that wasn't created through the modules.