Remove node-binding, enhance keyring-util, create github action

[MarkAckert]

This PR is part of the work to remove Node.JS as a dependency from zwe completely as tracked here: zowe/zowe-install-packaging#4307 .

Tests:

• Manual tests invoking this utility directly. Improvements could be made to error reporting and handling, but happy path tests work. This matches prior behavior.
• Automated integration tests from the zwe PR are working as expected. migrate for kubernetes pulls certificates out of the keyring and loads them into the Java keystore without an error.

This PR:

• Updates keyring-util to be built using Github actions, and removes the old Jenkinsfile.
• Updated some keyring-util compiler options. Uses xlclang to build, upgraded arch and target parameters.
• Deprecates and sidelines the node-binding section of the code. This may be removed after further discussion, for now it will not be built in the Github action.
• Brings the keyring-util to the forefront as the utility invoked by zwe. Enhancements include:
  • A slightly more refined command-line argument parser, though an external library like argp would work better longer term.
  • Adds LISTRING function to keyring-util. This was limited to the node-binding before and can now be invoked directly.
  • EXPORT now exports private keys from a keyring in PKCS12 rather than PEM. This was the sore point for integration with zwe, which loads the exported private key into a Java keystore. keytool did not accept PEM private keys, and openssl was not available to convert the PEM to another support format. The ncert utility previously did this conversion, but with GSK APIs, we can export directly to a password-protected p12 binary. The export format could be customized via command-line argument, but for now, private keys are always p12 and public certs are always cer formatted.
• This PR prefers to use GSK where available of R_datalib APIs, however, GSK APIs have limitations when compared to R_datalib. For example, the GSK APIs don't return complete certificate/keyring metadata (status, usage, trust), so LISTRING continues using R_datalib.

[Martin-Zeithaml]

Can we do two things here?

1. Change the extension to yaml to be consistent with other Zowe components
2. Add the build section? We can do it as another PR, I think this is usually made by some workflow:

...
build:
  branch: "master"
  number: "123"
  commitHash: "12345...."
  timestamp: 1746717018543

This might be handy in the future for various tasks, when the specific commit is needed.

[MarkAckert]

I updated the extension, and the build block should be left to another PR. I checked our action libraries and I didn't see any common code we could re-use, so we'll need to create it. It looked like the existing implementation is very specific to zlux.