CI - Publish wheels

[dave-gantenbein]

Issue description rewritten by @jgiannuzzi

Python wheels for major platforms (linux-amd64, linux-arm64, macos-amd64, macos-arm64, windows-amd64) should be published automatically when a release is cut.

• [x] Ensure that a wheel can be created via pyproject-build (I think that's already the case?)
• [x] Enable cross-compilation from macOS via zig cc -target - this will allow to compile each wheel in the most compatible way, as the glibc and musl implementations can be aligned to the most universal manylinux targets
• [x] (optional) Add a mage target that
  • creates a venv
  • installs the build Python package in it
  • installs the ziglang Python package in it
  • gets a target as argument (and defaults to the native target if none given)
  • calls pyproject-build with the right CC, GOOS, and GOARCH vars for the target
• [x] Add a build GitHub Actions workflow that builds the various wheels in parallel on a macos-latest runner (using the matrix statement) and uploads them as artifacts
• [ ] Add a publish GitHub Actions workflow that only runs on tag or release creation, downloads the artifacts, and uploads them to PyPI via trusted publishing. It should be tied to a specific GHA environment and this environment should be tied to protected tags.

The rationale for using zig is that we need CGO for using SQLite in mlflow-go, which means that classic Go cross-compilation wouldn't work. Zig ships with all the toolchains, as opposed to gcc/clang that need to install each toolchain independently. However, zig doesn't ship with the toolchains for macOS, so compiling from Linux or Windows for macOS is not possible. Luckily the fastest GitHub runners are actually the macOS ones with Apple Silicon (arm64), which can be used via the macos-latest runner tag. Hence my proposal to cross-compiling with it.

[nojaf]

@BenWilson2, as mentioned on the Slack channel, I believe we would need this repository to be registered as trusted publishing in Pypi.

[nojaf]

We are trying to publish to PyPi in https://github.com/mlflow/mlflow-go/actions/runs/11837339705/job/33029830166

however, we got:

Error: Trusted publishing exchange failure: 
Token request failed: the server refused the request for the following reasons:

* `invalid-payload`: The name 'mlflow-go' is too similar to an existing project. See https://pypi.org/help/#project-name for more information.

This generally indicates a trusted publisher configuration error, but could
also indicate an internal error on GitHub or PyPI's part.

The claims rendered below are **for debugging purposes only**. You should **not**
use them to configure a trusted publisher unless they already match your expectations.

If a claim is not present in the claim set, then it is rendered as `MISSING`.

* `sub`: `repo:mlflow/mlflow-go:environment:release`
* `repository`: `mlflow/mlflow-go`
* `repository_owner`: `mlflow`
* `repository_owner_id`: `39938107`
* `job_workflow_ref`: `mlflow/mlflow-go/.github/workflows/release.yml@refs/tags/v0.1.0`
* `ref`: `refs/tags/v0.1.0`

Do we need a different name for our project 🫠? @BenWilson2 @jgiannuzzi @dsuhinin any thoughts on this?

[nojaf]

Ben and I had a call yesterday, and PyPi is currently refusing to accept mlflow-go as the package name. Ben opened an issue at https://github.com/pypi/support/issues/5146, but it's unclear how long this will take. Our plan is as follows:

• Wait a few days to see if there is a response to the PyPi ticket.
• Try a manual publish from Ben's side, which might bypass the name validation.
• Rename the package.