Prevent releasing beta versions and newer major overrides for Brew releases

[kamilogorek]

1. Our Brew releasing workflow doesn't understand to not publish itself when a newer major is present, and it overrides it, which makes patches for older versions override the latest version.
2. Brew doesn't understand pre-releases, and it tries to install 2.0.0-beta.0 which is not available at the time of doing Crafts pre-prelease publish.

beta ref: getsentry/homebrew-tools#3
major ref: getsentry/homebrew-tools#5

[lforst]

Adding: It seems like our brew target publishes pre-release versions, like alphas, as latest. Which is no bueno.

[armcknight]

Regarding (1), Brew doesn't have a concept of release channels like you can use with gem install --version or pip install example-package>=2.0.1 that we could use to have parallel latest releases in multiple support series like 1.x.x and 2.x.x. The way other orgs solve this is by creating entirely separate formulas, like https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/p/postgresql@10.rb vs https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/p/postgresql@11.rb. AFAIK the @s aren't a feature of homebrew, they're part of the formula name used to namespace the different implicit major support series channels.

So what we really want is a separate homebrew formula for sentry-cli@1 and sentry-cli@2 that can each have their own "latest" release.

ETA: PostgreSQL use an option keg_only :versioned_formula with the all but their postgresql@14 formula, which I think is how they are supporting a workflow where brew install postgres will select the postgres@14 fomula (because they also have later versions too, 15 and 16, that I guess aren't their "officially supported latest major" ¯\(ツ)/¯ )