Add support for EKS AL2023 AMIs

What does this MR do?

MR refactors the EKS Node Group AMI approach to handle the release of Amazon Linux 2023 optimised AMIs (which are scheduled to become the default in upcoming EKS 1.30 release) and the ramifications of handling multiple AMI choices as follows:

• Added ability to directly set the Node Group AMI Type - This directs what AMI is to be used for the Node Groups if no custom AMI is passed.
• Default Node Group AMI type handling for upcoming AL2023 default switch in 1.30 has been added
• SSM searches for latest standard AMI release version now always follow the AMI type by translating accordingly
• Changed eks_ami_id variable name to eks_node_group_custom_ami_id to better reflect it's meaning. Old variable name is now deprecated and schedule for removal in 4.x release.
• Added handling for different custom AMI user data scripts as any custom AMI based on AL2023 will use a different approach from the previous bootstrap method named nodeadm. Script templates have been updated and a new param, `eks_node_group_custom_ami_userdata_type, added to configure.

Related issues

Closes #862 (closed)

Author's checklist

When ready for review, the Author applies the workflowready for review label and mention @gl-quality/get-maintainers:

• Merge request:
  • Corresponding Issue raised and reviewed by the GET maintainers team.
  • Merge Request Title and Description are up-to-date, accurate, and descriptive
  • MR targeting the appropriate branch
  • MR has a green pipeline
  • MR has no new security alerts in the widget from the Secret Detection and IaC Scan (SAST) jobs.
• Code:
  • Check the area changed works as expected. Consider testing it in different environment sizes (1k,3k,10k,etc.).
  • Documentation created/updated in the same MR.
  • If this MR adds an optional configuration - check that all permutations continue to work.
  • For Terraform changes: set up a previous version environment, then run a terraform plan with your new changes and ensure nothing will be destroyed. If anything will be destroyed and this can't be avoided please add a comment to the current MR.
• Create any follow-up issue(s) to support the new feature across other supported cloud providers or advanced configurations. Create 1 issue for each provider/configuration. Contact the Quality Enablement team if unsure.