Julia: support `language_version`

[ericphanson]

Adds basic support for customizing the Julia version by setting the JULIAUP_CHANNEL environmental variable. This support is limited in a couple ways:

• We don't check that the user is using juliaup. They could have installed julia some other way in which case the JULIAUP_CHANNEL does not do anything and setting the language_version will not have any effect. That however is the status quo (currently setting the language_version does not have any effect) and many users use juliaup, so I think we could just document that language_version support requires your julia to be from juliaup.
• If the user passes a channel which is not installed, they will get a juliaup error that the channel can not be found. If we were confident they were using juliaup we could install it on their behalf instead, but I'm not sure this is necessary.

split out from #3494

[asottile]

so while this seems to work it sort of doesn't fit nicely with pre-commit. normally language_version support means that pre-commit will install the particular programming language version into the pre-commit environment such that there's no "external" dependencies on the host itself (in the docs this is referred to as first class language support). I believe this patch doesn't do that -- it instead relies on an external version manager to keep that in sync and so it doesn't fit the same properties as pre-commit does today.

basically for actual language_version support one should be able to pick up the pre-commit cache and drop it on a relatively-similar empty operating system and still have it work (for first class language support)

if I understand correctly language: rust does a similar approach (rustup vs juliaup) and maybe the approach there can be copied here?

[ericphanson]

I did see (and was surprised) that rust installs an entire tool chain. It seems entirely unnecessary to me, as one Julia installation can be used conflict-free by many users (it is different than python where it avoids a lot of issues to make many installs). I think that would be possible here too, but I’m not very interested in it personally, it seems like a lot of disk space for no gain.

Can something like this be acceptable as non-first class support?