Read version from resource instead of hard-coding it

[naveenOnarayanan]

• Seems like the hard-coded version keeps drifting everytime a new release is made (current release 7.1.0, but code still shows 7.0.0).
• This uses resource jar approach to embed the version into the binary and read it at runtime. This ensures that the version is always up to sync with release.

> git tag -a 7.1.1 -m "Version bump" 

> bazel-out/darwin_arm64-fastbuild/bin/cli/bazel-diff --version
7.1.1


# If built off master (no tags)
> bazel-out/darwin_arm64-fastbuild/bin/cli/bazel-diff --version                                                                                ✔
acd415a165d8515d9d94be18f14dcd62d0c1bf1c

[CLAassistant]

All committers have signed the CLA.

[tinder-maxwellelliott]

Thanks for doing this

[tinder-maxwellelliott]

This looks good. We need to use a different version file then this one since this one controls the version of Bazel that is running, not the version of bazel-diff

[naveenOnarayanan]

Oh oops, currently when the binary is published, how is the version passed in? I see that since it follows semvar, it seems like it might be provided from the pipeline itself?

[naveenOnarayanan]

ah looks like it picks it up from tags.

[naveenOnarayanan]

@tinder-maxwellelliott correct my assumption above, updated the PR to utilize bazel stamping to embed the version tag and read it directly from the binary resources instead.

[tinder-maxwellelliott]

Does it make more sense to simply make a bazel rule that can accept the stable-status path and code gen this entire file? Seems like there are a couple steps here that could be collapsed into one?

[tinder-maxwellelliott]

Thanks for doing this