Fix toolcache behavior when downloading bundle from another repo

[henrymercer]

Suppose a user requests a specific version of CodeQL by passing a tools: https://github.com/dsp-testing/codeql-cli-nightlies/releases/download/codeql-bundle-20230203/codeql-bundle.tar.gz input to the init Action.

Previously the Action did not take note of the fact the bundle came from dsp-testing/codeql-cli-nightlies, not github/codeql-action. Most of the time, this would mean it wouldn't find a release with the requested tag, and the bundle would be correctly cached as 0.0.0-<bundleVersion> so as to avoid a clash with a stable CodeQL release. However if a release with the same tag existed on the CodeQL Action repository, then the Action would incorrectly associate the CLI version number from that stable bundle with the other bundle, and go on to cache the bundle as <cliVersion>-<bundleVersion>. This led to bundles being cached with the wrong CLI version, for example https://github.com/dsp-testing/codeql-cli-nightlies/releases/download/codeql-bundle-20230203/codeql-bundle.tar.gz was cached as 2.12.2, since it matched this release on the github/codeql-action repo.

To resolve this, before we try to look up the CLI version number associated with a particular bundle tag, we check that that bundle originates from github/codeql-action, either the original repository on Dotcom or a synced repository on Enterprise Server.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Confirm the readme has been updated if necessary.
• Confirm the changelog has been updated if necessary.

[aeisenberg]

I think this makes sense, but I did want to have a chat with you about URLs and verifying them.

[angelapwen]

Thank you 👍 looks good to me and regression test makes the change quite clear!

(Didn't notice Andrew had already just approved 😅)