Support optional custom cacerts input for installed JDK

[brunoborges]

Summary: Add an optional action input that allows providing a custom cacerts file to be used by the installed JDK.

Background: PR #284 proposed this capability, but the branch is now very old and heavily conflicted. The feature request can continue in a fresh implementation.

Proposed behavior:

• New optional input for path to a cacerts file
• If provided, configure the installed Java runtime to use that cacerts content
• Keep default behavior unchanged when input is not set

Scope:

• Re-implement on current main instead of reusing the old branch
• Add tests for enabled and default paths
• Document usage and caveats for hosted and self-hosted runners

Out of scope:

• Unrelated runtime or lockfile changes

Reference: PR #284

[brunoborges]

Related (but distinct) to #640. For clarity: #1035 (this issue) is about the installed JDK's runtime cacerts trust store; #640 is about the action's download-time TLS (verifying an internal CA while downloading the JDK on GH Enterprise). Different layers — cross-linking so they're tracked together but not merged.

[brunoborges]

Rather than adding a dedicated cacerts action input, this is solved cleanly with documentation, since the installed JDK exposes its own trust store at $JAVA_HOME/lib/security/cacerts and keytool can import a custom CA after setup-java runs.

• docs: self-signed certificate / internal CA handling for GitHub Enterprise #1050 (merged) documents the download/transport layer — making the runner trust an internal CA via NODE_EXTRA_CA_CERTS so the JDK can be downloaded on GitHub Enterprise / behind a TLS-inspecting proxy.
• docs: document importing an internal CA into the installed JDK (cacerts) #1051 (open) adds the JDK runtime layer this issue is about: a post-install keytool -importcert step into $JAVA_HOME/lib/security/cacerts, with hosted vs self-hosted persistence caveats.

A built-in input would add config surface, tests, and maintenance for something a single documented step handles, so we'll go with docs. Closing as resolved-by-documentation; see #1051 for the exact guidance. If a first-class custom-cacerts input is still desired later, we can reopen with that specific scope.