feat: support for external mainnet canisters in the bazel workspace

[mraszyk]

This PR adds support for external mainnet canisters in the bazel workspace.

In more detail, this PR

• represents external mainnet canisters by their git tag in the mainnet canister json file;
• updates that git tag automatically using the existing bot for NNS canisters extended to
  • crawl all git tags of the corresponding (hard-coded) external repository (e.g., dfinity/cycles-ledger);
  • for every git tag, list all release assets;
  • look for a release asset whose name has the form {canister_name}.sha256 where canister_name is hard-coded (e.g., cycles-ledger.wasm.gz);
  • if that release asset starts with the expected module hash of the external canister (as fetched from the ICP mainnet using an IC agent), then the corresponding tag is updated in the mainnet canister json file;
• uses GITHUB_TOKEN to prevent rate-limiting;
• adds the mainnet cycles ledger canister to demonstrate how external mainnet canisters are handled.

This PR has been tested manually by changing the module hash and tag of the mainnet cycles ledger canister in the json file and running bazel run //rs/nervous_system/tools/sync-with-released-nervous-system-wasms to confirm that the json file is properly regenerated.

Follow up improvements of the NNS bot are tracked in this ticket.

[github-actions]

This pull request changes code owned by the Governance team.
Therefore, make sure that you have done the following (for
Governance-owned code):

1. Add entry(s) to corresponding unreleased_changelog.md
   file(s). This is only necessary if the code changes result in
   externally visible behavior changes.

2. If there are behavior changes, are they breaking? This is
   usually due to some new requirement(s) imposed by the canister,
   or removal of guarantees supplied by the canister. If the
   changes are breaking, are your clients ready for them? If not,
   put your changes behind a "feature flag". If you have a feature
   flag, then, do NOT add entrie(s) to unreleased_changelog.md
   in this PR, but rather, do that later when you set the flag to
   "enable" in another PR.

3. Is data migration needed? (If so, make sure it is part of this
   PR.)

4. Does this require security review? At the very least, you can
   tell security team about this PR, and let them decide whether
   the risk warrants their review.

To acknowldge this reminder (and unblock the PR), dismiss this
code review by going to the bottom of the pull request page, look
for where it says this bot is requesting changes, click the three
dots on the right, select "Dismiss review", and for each of the
numbered items listed above, supply one of the following reasons:

• Done.

• $REASON_WHY_NO_NEED. E.g. for unreleased_changelog.md, "No
  canister behavior changes.", or for item 2, "Existing APIs
  behave as before.".

To be more precise, "externally visible behavior change" usually
means that responses differ in some way. However, "externally
visible behavior change" is not limited to that. For example, it
could also means that the canister makes different requests to
other canisters.

For a more comprehensive checklist, see here.

GOVERNANCE_CHECKLIST_REMINDER_DEDUP

No canister behavior changes.