Add .tool-versions

[doorgan]

The README.md suggests to use those versions, and the pre-commit hooks
depends on the formatting done by that elixir version. Having a
.tool-versions file helps making sure the right versions are being
used if the developer is using a version manager like asdf. Otherwise
the global elixir and otp versions will be used, which changed formatting
rules after 1.13.4.

[lukaszsamson]

-1 from me. I dislike locking versions when the project has to work on a wide range of versions. It makes testing cumbersome as the first thing I do is delete the .tool-versions and then I need to check to not commit it accidentally. I quite often run a custom elixir build with some local patch applied

[doorgan]

I have the opposite issue, I need to work with expert on a different elixir and otp version than my globally configured one(1.18), otherwise I can't commit due to formatting issues, so I need to create the .tool-versions file (with asdf local elixir ...) and then remember to not commit it.
Not sure if there's a good solution that covers both

[Moosieus]

I err on the side of including .tool-versions.

Expert works on a wide range of versions so long as it's compiled with a minimum version below them. The tentatively discussed version support is Elixir 1.15 + OTP 25 and later, so it's helpful to ensure tests pass on that version.

If/when Expert gets bundled with Burrito, we'd/ll be at liberty to use any version of Elixir + OTP for the server node. Project nodes will run on the user's local version, so there's still a constraint there for the time being.

[Moosieus]

May also consider bumping the CI check for 1.15.6 to 1.15.8 and drop the CI checks for 1.13 and 1.14.

[scohen]

we didn't have a .tool-versions in lexical because so many people use asdf/mise and compile it from source, including a tool-versions would mean they can't do so.

[scohen]

I'm going to close this; I agree with @lukaszsamson about making the project difficult to test in a variety of versions.