Allow alternate manifest options (GHES)

(Filing here for discussion, and because while there will need to be enhancements to setup-python/setup-go/setup-node as well, they're all similar and have common code here.)

On GHES runners, the setup-python/setup-go/setup-node situation is not ideal. As documented, github.com has a very low unauthenticated API limit to the point of not being usable for anything above small scale. The workarounds are:

• Have the workflow's repo owner keep a github.com PAT in their GHES secrets and then do e.g. token: ${{ secrets.API_TOKEN_GITHUB_COM }}. This is not user-friendly, since it creates an individual burden on the user and is a difference compared to the github.com experience.
• Build runner images which have /opt/hostedtoolcache populated with the latest revision of each minor version of each toolset. This is what I do with our GHES (and adds about 3GB to the runner image -- needed because the runners are being run completely ephemeral), but if a user wants a specific revision, they still have to do the token workaround above.

It would be nice if my organization could maintain our own manifest and a central cache of the toolsets, and the actions would automatically use that.

I'm thinking several options, all of which could be implemented together:

1. Look in path.join(_getCacheDirectory(), toolName, 'versions-manifest.json') on the runner for the manifest, and use that if present. I'm building base runner images on a weekly schedule anyway, so it would be preferred to just have e.g. /opt/hostedtoolcache/Python/versions-manifest.json on my runners. If only one of these options could be implemented, this would be my preference.

2. Look for the environment variables RUNNER_TOOL_MANIFEST_URL_PYTHON, RUNNER_TOOL_MANIFEST_URL_GO, RUNNER_TOOL_MANIFEST_URL_NODE. If preset, the URL will be retrieved and used. These variable values could be baked into the runner at build time (or overridden by the job, but manifest-url would be preferred).

3. Add a manifest-url input to the actions. The user would still need to have a different configuration vs the public experience, but at least it would not require the user maintaining an account on a foreign (to our GHES) site.

The order of checking would be:

1. manifest-url input
2. RUNNER_TOOL_MANIFEST_URL_* variable
3. versions-manifest.json on disk
4. Current API method

Thank you!

Start by locating the shared manifest-handling code and tracing how setup-python, setup-go, and setup-node currently obtain manifests. Review the proposed local path, environment variables, and manifest-url input, including their precedence. Done requires an agreed design for alternate manifests that works consistently across the three setup actions.