Tweak Ansible collection version handling further

What does this MR do?

Follow up from !909 (merged)

On further reflection, Ansible collection versions are a bit of a weird one. The main ansible package comes with many collections included, that get updated with each Ansible release. However sometimes newer versions of the collections can have fixes that we want to consume and we also need a minimal list at least for ansible-core versions that come with no collections.

Due to this we're in a bit of a catch 22. We could pin the collections completely but then they would eventually mismatch with the versions that come with the official ansible package and may not be supported.

We try to be as wide as possible for Ansible and only specify minimum versions. On balance this seems to be the best approach for the collections as well at this time. MR switches to this approach.

MR also adds the AWS collections now to also be handled by Galaxy as slightly newer versions contain a fix for AWS SSM that are verified by collection authors to work with Ansible 6 (our current version).

Note this is a MVC approach for now and with the next GET release we will be adding in Ansible 7 support and will revaluate there.

Related issues

Relates #564 (closed) #599 (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.