ci: fix build-tools installation in GH actions workflow

[tylerbutler]

The push-tag-create-release workflow creates GitHub releases when release tags are pushed to the repo. This automates the creation of the GH release. Without this change, the workflow fails, and GH releases are not created.

In #20972, build-cli (flub) was updated to ESM. Prior to that change, we had a hacky flub shim in the bin folder, alongside the files that oclif uses (and what's in the bin folder). We did that so we could add the path to build-cli/bin to the PATH, and then flub commands would work. This enabled us to use flub commands directly in CI scripts just like one would do locally.

That shim was removed with the change to ESM, and we instead use npm link to make flub available on the PATH. The shim was likely never really needed; we could have used this approach the whole time.

Tested with act:

act push -W .github/workflows/push-tag-create-release.yml -v

AB#8474

[CraigMacomber]

Its unclear to me what the exact change is that causes us to need this change. It seems like moving build-tools to ESM removed something from its /bin that we need, but its still in some bin folder that npm link exposes? What file no longer exists and what was it replaced by? Is there a reason not to just use a path to the new file? Is there a reason the new bin is not in the same bin folder? There is no lib or dist in the path, just /bin, so I don't think that's the issue. There arn't enough details in the change itself or the PR description to answer these kinds of questions which makes it hard for me to review this with what little context I have.

[tylerbutler]

Its unclear to me what the exact change is that causes us to need this change. It seems like moving build-tools to ESM removed something from its /bin that we need, but its still in some bin folder that npm link exposes? What file no longer exists and what was it replaced by? Is there a reason not to just use a path to the new file? Is there a reason the new bin is not in the same bin folder? There is no lib or dist in the path, just /bin, so I don't think that's the issue. There arn't enough details in the change itself or the PR description to answer these kinds of questions which makes it hard for me to review this with what little context I have.

I added some more detail to the PR description. I think the reason the hacky shim ever existed was because I couldn't find a way at the time to make it work without it. I wanted to make sure that the commands used in CI scripts used flub instead of something like bin/run.js.

Knowing what I know now, all of that was unnecessary with proper use of npm link (pnpm link doesn't work - haven't investigated more deeply).