Refactor CI/CD into a single workflow file

[kotabyte]

Summary

The existing CI/CD workflows had several issues that prevented them from functioning correctly on forks and in general use. This PR consolidates build.yml and publish.yml into a single release.yml workflow that is simpler to follow and more reliable.

Changes:

• Merged build.yml and publish.yml into a single release.yml to eliminate workflow_run chaining between separate workflow files
• Added a check job that verifies a release tag doesn't already exist before wasting runner time compiling
• Added dev branch support for Docker image publishing (:dev tag alongside :master)
• Fixed workflow permissions to explicitly declare contents: write and packages: write where needed
• Updated actions to current versions (upload-artifact@v4, build-push-action@v6, etc.)

Notes

Multi-arch Docker support (linux/amd64, linux/arm64) is intentionally excluded from this PR as it is already being addressed in #154 by @Shion1305. That fix should be incorporated once their PR lands.

Also please squash my commit history, I made too many commits

[kotabyte]

Just updated my CICD file because I realized that the source code isn't attached on releases made by the runner

[machawk1]

Hi @kotabyte, we have concerns about merging this PR. Can you tell us which issues you are experiencing that are not functioning correctly on forks? /cc @dcalano @ibnesayeed

[kotabyte]

Hello @machawk1, thanks for taking a look at my PR. May I ask about the concerns you guys have?

When I forked this, the CICD pipeline never ran, which you can see for yourself on the actual main repo too. The point of my PR is to "modernize it" and make it efficient. When a maintainer makes a new release, the source code and binaries are automatically updated and released, same with the docker images. I also believe it's important to have docker images be sorted by releases, like release 1.0-rc9 as a tag. master as a tag, dev as a tag (if you all choose to use dev, if not I can just remove it), so on and so forth.

I also wanted to get rid of having two different files so we do not need to reference workflow_run.

[ibnesayeed]

Build and publish two separate workflows are intentional and they trigger on a different set of events. The point of the build workflow was to have a test of builds and catch any issues at the time of push or PR against any branch. This should work across all the forks (or it was intended to do so), if that is not happening, the build workflow can be be improved to address any issues. On the other hand, publish workflow is only triggered when a change is pushed to the master branch or a release is tagged, so that only stable state is published. This one is aimed to run only on the main repo, not from any forks.

[kotabyte]

So I suppose the question now is what should I change from my implementation? I would be happy to contribute to the repo if I'm able to.