expert: use recommended build method

[AlternateRT]

---

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>?
• Is your test running fine brew test <formula>?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

This switches away from the burrito build method and moves towards the recommended plain one instead, which should address the points made in elixir-lang/expert#556 (comment) and elixir-lang/expert#557 (comment), and removes the zig and xz dependencies.

[SMillerDev]

I think homebrew having to maintain a shell script is a big regression and I think that should block this PR from merging.
The old way was an easy script where the whole install was maintained by upstream, this makes a bunch of it specific to Homebrew, where nobody is involved in the upstream project.

[AlternateRT]

The old way was an easy script where the whole install was maintained by upstream

@SMillerDev The problem with the Burrito method was that it downloads its own precompiled Erlang binaries, which can fail if the Burrito project has not yet made said binaries, like it did here: https://github.com/Homebrew/homebrew-core/actions/runs/24078956292/job/70250704538?pr=276421#step:3:1662

There is also the issue that Burrito expects a patch-specific version of Zig to work. At the moment, that version happens to be latest one available (0.15.2 as of this writing).

But if the Zig project releases a 0.15.3 version, that will be a problem when Homebrew updates the Zig formula.

---

For the record, this is really just a rewrite of the start_expert executable, which is currently being unlinked on line 34 because it does not work when symlinked (it expects the plain executable to be in the same directory).

After investigating a bit more, I think we could cleanly change this to use the inreplace function instead, like so:

    inreplace libexec/"bin/start_expert", '"$(dirname -- "$0")"/plain', "\"#{libexec}/bin/expert\""
    bin.install_symlink libexec/"bin/start_expert" => "expert"