ci: Test via Community Hub orchestrated GitHub Actions

[slothkong]

Hello @pacospace ,

This is the pending PR to enable on-demand ewccli-centric test automation.

What is new
This is analog to the PR ewcloud/ewc-ansible-playbook-flavours-and-provisioning#12.
The key differences are:

• The workflow is defined in this same repo (as opposed to being a self-contained GitHub action on an external repo)
• The workflow is built specially to support triggering Items via the EWCCLI

I went ahead and added all the necessary action secrets for the EWCCLI to be able to login the test tenacies, namely:

• ECMWF_ANSIBLE_SSH_PRIVATE_KEY
• ECMWF_ANSIBLE_SSH_PUBLIC_KEY
• ECMWF_EWC_CLI_LOGIN_REGION
• ECMWF_EWC_CLI_LOGIN_TENANT_NAME
• ECMWF_OS_APPLICATION_CREDENTIAL_ID
• ECMWF_OS_APPLICATION_CREDENTIAL_SECRET
• EUMETSAT_ANSIBLE_SSH_PRIVATE_KEY
• EUMETSAT_ANSIBLE_SSH_PUBLIC_KEY
• EUMETSAT_EWC_CLI_LOGIN_REGION
• EUMETSAT_EWC_CLI_LOGIN_TENANT_NAME
• EUMETSAT_OS_APPLICATION_CREDENTIAL_ID
• EUMETSAT_OS_APPLICATION_CREDENTIAL_SECRET

UPDATE: I patched the workflow to clean up dangling Floating IP, as per discussion on #69

IMPORTANT
The issue of --item-inputs not being properly processed by the EWCCLI persists (see #60).
Please note however, that said issue is NOT A BLOCKER for this PR, for three reasons:

1. The orchestrator running as part of ewc-community-hub does not force down any inputs onto this downstream workflow; rather the EWCCLI reads inputs automatically from the catalog medatadata.
2. Overriding inputs defined in the catalog metadata is considered a feature to enable trobleshooting, not necessary for the typical release cycle of Items or EWCCLI versions
3. The moment the EWCCLI if fixed, any input overrides from this workflow will be accepted and execution would proceed as expected.

[pacospace]

LGTM!