add lts field

[M-PERSIC]

Add an "lts" field to each tag in the JSON release feed. This is set via the JULIA_LTS variable in the CI workflow, which only requires that the major and minor version numbers match (no need to manually set for every patch release). Tested locally with LocalStack.

This is a follow-up attempt from #32 which broke the Buildkite plugin. It was thereafter decided to simply include lts tagging as a new field for each release tag, rather than it be its own tag. It will be up to downstream consumers to select the most recent lts release, since every patch release for the given version will possess "lts": true.

Closes #2

@IanButterworth @DilumAluthge

[IanButterworth]

Looks good. I was expecting only the latest patch to be marked as lts but I guess this makes sense.

[M-PERSIC]

Indeed, I did debate that before deciding on the current behaviour. Every patch release for a given version does on its own count as an lts release. I find it also fits the current behaviour with the stable field, since one needs to find the most recent stable release by filtering all version tags with "stable": true.

[DilumAluthge]

Seems a little odd to mark every single patch with the lts tag, but it sounds like this is consistent with how stable currently works?

What happens when a new LTS is chosen? Do the old LTS versions keep the lts tag?

[IanButterworth]

It seems correct to me. The patch releases are all part of the LTS release minor version.

[M-PERSIC]

That is a good point. I can follow up with another pr that can maybe take advantage of YAML multi-line strings so that multiple lts releases can be added. Will need to try this out myself first.

I agree that it does look odd in the release feed. This could probably be improved upon with a new version of the JSON schema along with other improvements (potential GSoC proposal :) ).

[M-PERSIC]

Hold that thought, actually. I might be able to implement it here instead, especially because I don't want to accidentally skip the last lts release (1.6).

stale

[M-PERSIC]

Turns out I was overthinking this. We can simply list all the lts releases in JULIA_LTS and just slightly rework the is_lts function. All past and present lts releases (v1.0, v1.6, v1.10) are now properly listed as such. With the limitations of the current schema, downstream consumers follow the same logic as with the stable field (choose the latest stable/lts release).