.github, elixir: support publishing in ci

[npry]

Support publishing ts_elixir to Hex in CI. Supports a push to staging.hex.pm via workflow_dispatch input. The hex.pm environment is locked down to require a separate approver, though admin override is permitted.

Removes dependency on ts_cli_util since that breaks things if we do want a version dep.

Provides a script (used only in ci, right before publishing) to alter the ts_elixir Cargo.toml to strip all the workspace details from it, since we're currently source-distributing. Notably: since the version of the Cargo.toml uploaded to hex.pm doesn't need to be the same one uploaded to crates.io, I currently specify a git dependency pinning to a specific rev in this repo (via github.sha) instead of the crates.io version. That removes the ordering dependency where we need to publish the crate strictly before the elixir package and makes version solving more deterministic (each elixir version is pinned to a specific version of the Rust — acting more like a precompiled included library semantically). That also means that the hex package won't see patch fixes, but we'd presumably want that to happen through a synchronized release anyway.

Provides another script that tries to push all our deps to staging.hex.pm so that we can actually push the tailscale package — it doesn't share a db with prod, and it seems like they wipe it sometimes, as the popular packages aren't there, and we need them there to make hex.publish work.

[dylan-tailscale]

lgtm, one potential issue

[dylan-tailscale]

Suggested change

	if: ${{ startsWith(github.ref, 'refs/tags/*') || github.event_name == 'workflow_dispatch' }}
	if: ${{ startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch' }}

I don't think you want the wildcard here? If it is required, I need to fix that for Python lol

[npry]

lol nope, you're right