Added CI worker for native S390X

[fneddy]

Background

As mentioned in #1050 Qemu does not implement the hardware acceleration instructions for S390X. Therefor a Qemu based CI will never actually test the code but fallback and use the software implementation. For this reason its highly desirable to run the zlib CI on a real S390X IBM System Z worker.

Setup

This PR adds CI jobs for native S390X workers.
GitHub has not yet support for this architecture. Therefore its necessary to add self-hosted workers.
Marist University offers free workers for open source projects with their LinuxONE Community Cloud.

Job Control

The self-hosted worker setup does not allow forks to run their CI jobs on the worker. Therefor it is necessary to deactivate this new jobs for forks.
Currently its not possible to deactivate or skip a GitHub Action Job. Therefor I added an enabled flag to the cmake and configure job matrix. Together with a repository check (${{ github.repository == 'madler/zlib' && 'true' || 'false' }}) the new CI jobs can be disabled for forks. By filtering on this flag in the job steps forks could be set to always succeed or always fail .

S390X worker

GitHub does not officially support S390X as a worker. With gaplib its possible to connect an S390X instance as a self-hosted worker.
This raises some questions: Should we add the gaplib-scripts to the zlib src (zlib-ng did that). Who will maintain the self-hosted worker at the LinuxONE Community Cloud? I've already setup an account for testing and am willing to take this responsibility. But if its decided that it should be maintained by an official zlib maintainer I am happy to assist with the setup. If I shall maintain the worker, I need a communication channel with a zlib maintainer to exchange the github tokens.

Open Questions

• should the native S390X CI run on forks be always failing or always success ? -> @fneddy votes for always success
• should gaplib scripts be added to the contrib folder? -> @fneddy no / @iii-i yes
• who will maintain the LinuxOne Instance -> @fneddy
• how will the zlib github token find its way to the LinuxOne instance -> email to @fneddy encrypted via smime or pgp

[madler]

You would need to maintain the worker, and I am the only maintainer with which to exchange tokens.

[fneddy]

this PR is ready for review.

i left this in the code: enabled: ${{ github.repository == 'fneddy/zlib' && 'true' || false }}
If I change it to madler/zlib before the actions workers are connected it will create stalling actions.

next steps:

• review
• add actions worker to madler/zlib
• change last repository names in the runner config
• merge the pr