Support inter-dependency sync tags

[somewhatabstract]

Problem

Sometimes, we may want to sync code between different repos in a manner that is non-programmatic. For example, I may have a golang project and a javascript project in separate repos that need to have some common code, but that we don't really want to create some sort of code dependency between them.

In addition, just coming up with a way to reference these things and then doing the sync check "live" would be dependent on network requests or some need for the code to be available locally all at the same time, which would make automated checks such as in GitHub Actions hard, slow, and possibly impossibly.

Proposed Solution

1. The CheckSync tool is already run across all files in a project to "lint" for sync issues and verify all the checksums are correct.
2. This run outputs a summary of broken sync tags.

We can update CheckSync to:

1. Output a verbose summary of ALL sync tags, whether broken or not
2. Allow configuration to import such summaries as a proxy for scanning the real files

With this mechanism, repo A can make available in a commit, the complete output defining all sync-tags and checksums for their content. Then repo B can reference that file in its config along with the commit SHA of the last repo A commit it was updated from (based on the repoA commit where the summary file was last changed).

When CheckSync runs in repoB, it can:

1. Verify that it has the latest version of the sync summary file from repoA
2. Load the version that it has locally and use that to verify any sync tags that target repoA files.

We can also add the ability to update the repoB source with a new sync file from repoA and update the commit SHA in the config accordingly. And likewise, repoA can use this mechanism to target repoB.

For things that are direct dependencies, like other JavaScript packages, one would expect them to share code somehow rather than need sync-tags. However, if they do require sync-tags (perhaps non-code files that we want to be reminded to update such as docs related stuff), then rather than needing to go look at actual git repos, the code could first check the local package files for the summary file and load it from there.

Illustration

1. Run checksync on repoB
2. checksync gets latest commit that the repo A summary was changed (likely via GitHub APIs?) and verifies the SHA matches the summary repoB already has, if it dosn't it raises a high-level sync issue in the output. At this point, we could fail early, continue as if everything was fine but note the issue, or if auto-fix was on, downloaded the updated file and update the config
3. checksync loads the repo A summary to match repo B synctags against and continues on its way
4. checksync outputs repo B's summary ready for inclusion in the commit - if it didn't change, it won't get committed

[somewhatabstract]

#2009 deals with this in a less robust but easier to achieve manner.

[somewhatabstract]

I think that if this is ever done, it really depends on getting #2055 done first.