Update get-list scripts to support lit 3.9.0 and luvi 2.15.0

[SinisterRectus]

No description provided.

[truemedian]

Some consideration should be applied that this change will cause anyone using get-lit with the $LUVI_VERSION environment variable less than 2.15.0 (such as potentially in automated testing or likewise) to suddenly start failing.

[SinisterRectus]

Is it enough to just make the url conditional then?

[truemedian]

I believe so? Nothing else here should be breaking with this change

[SinisterRectus]

Sounds good, except I'm too lazy to write logic for semver comparisons in languages that I don't know. I'll change this to a draft for now.

[Bilal2453]

A pure sh semver comparison is going to be annoying. The easiest way is to depend on gnu coreutils such as sort -V. should be fine.

[SinisterRectus]

Alternatively, the script can fallback to the old url format if the new one fails.

[truemedian]

Honestly this change is also a pretty good chance for us to rework how this works in the first place, what are thoughts on creating a new repository that packages releases for luvi+lit+luvit all in one .tar.xz or .zip.

Then git-lit can be simplified to a single download + extract and we completely bypass handling any weird edge cases like how to handle one download failing and one succeeding.

[Bilal2453]

Sounds good, but do we need a new repo for that? I feel like a number of existing repos can already fulfill that.
Would also be neat if the action automatically triggers on releases/tag creation

[SinisterRectus]

My only hesitation to providing prebuilt luvit and lit binaries is that this opposes our message that luvi apps are supposed to be easy to build on the fly. It is convenient, though, so I support it overall. I do not have an opinion on how they are hosted.