Build releases as .ez archives instead of escripts

[JakeBecker]

Right now, the language server and debugger are packaged as escripts that doesn't embed Elixir, and then we use a shell script to locate your Elixir install and set ERL_LIBS. Asdf, however, wraps your Elixir binary in an additional shell script which means it's harder to find the Elixir install.

This isn't a good way of packaging it, and I'm refactoring it to build a set of .ez archives instead. Then we can run it as ERL_LIBS=<release dir> mix elixir_ls.language_server, which should be much more robust.

[untra]

Would it make sense to offer the language server as a mix archive? If that was an option, then could other services start the server by calling the mix task (eg. mix exls start, or something like that?)

It would also mean installation is similar to phoenix or credo: mix archive install https://github.com/phoenixframework/archives/raw/master/phx_new.ez. That installation consistency would be greatly appreciated by the community.

It would normally not be a good idea to provide elixir-ls as a mix archive because it requires consumers to have elixir installed and on their path. But because this is a language server, that would actually be the case.

The only difficult part I can tell would be getting the stdio and logger backend to communicate through mix stdio.

[JakeBecker]

Packaging it as an archive makes sense, but installing it like that would mean that it's in the load path anytime you use a Mix application. That's okay for small scripts, but ElixirLS uses a few external dependencies like Poison that would have to be packaged and installed as well, and then there could be interference between ElixirLS's packaged Poison version and the versions in users' Mix apps.

My current plan is to package it as a set of archives and then add it to the path with ERL_LIBS when launching the IDE extension.