Binary-only releases should still have a Hackage release

Binary-only releases, such as HLS 2.9.0.1, did so far not have an accompanying Hackage release.
This is fine for HLS itself, but leads to worse UX for GHCup which provides an interface for compiling HLS binaries from source using the `ghcup compile hls` interface.

The issue is when users want to build from source, for whatever reason, the users' instinct is going to be to use `ghcup compile hls -v `. However, when using the `-v` flag, GHCup is going to build HLS from Hackage. If the `` is a binary only release, such as `2.9.0.1`, then the most straight forward GHCup invocation is going to fail, as we didn't upload that version to Hackage.

There are workarounds, such as using a git tag or using an older version that is on Hackage. However, that's way worse UX for GHCup user (for various reasons). While we *could* discuss whether we should build from Hackage, I think a hackage release is trivial for us to do, and avoids some confusion.
In particular, people *are* sometimes wondering why the latest release and the Hackage release are out-of-sync.

So, I am proposing to amend our release process for binary-only releases, to always include a Hackage release in the future, even though the release of 2.9.0.1 would be exactly the same as 2.9.0.0.