Instill devops culture

# Why?

*Reproducible operating environments* all the way from development to production are [proven](https://www.goodreads.com/book/show/39080433-accelerate?from_search=true&from_srp=true&qid=DYGqe8coUf&rank=1) to universally increase time to market, maintainability, cut development costs.

*Rolling release* strategy can be crucial for agile software, which XMage is, since it's being developed by adding cards, normally, with tiny patches.

# What?

## Finalise the @allentiak's work on making the codebase compatible with modern JDK/JRE

### Immediate action points

- [x] Remove changelog viewing functionality, which seems to be the only thing in the codebase that depends on JavaFX
- [x] Remove tests covering changelog viewing functionality, if any
- [x] Remove JavaFX dependency
- [x] Playtest JDK11 builds
- [x] Merge @allentiak's PR

### Further work

- [x] Rewrite changelog viewer without JFX

## Decrease the responsibilities of launcher

Launcher is a piece of software that is clearly loved in XMage community, but it is also a source of woe, since it's capable of destructive updates. Also, launcher is a bit of a pipe dream anyway. If it was a one-click installer for XMage, we wouldn't have had a "how to install XMage" video recorded in [every](https://discord.com/channels/169970997389295616/829432362768138280/829432753241980929) [community](https://discord.com/channels/528728694680715324/794483226747469825/794496730162397194) [out there](https://www.youtube.com/watch?v=80vczBW4dtY).

### Immediate action points

I propose that we keep launcher doing just what it's great at as it is, which is:

1. Being a thin piece of software which can be compiled against latest JRE / JDK
2. Installing a compatible, portable OpenJDK / JRE version into the directory it's ran from (we can have license problems with automatic provisioning of OracleJRE/JDK)

- [ ] Remove other functionality, including the capacity for [destructive] updates.

### Further work

I propose that moving forward, we turn launcher into something resembling [`asdf`](https://github.com/asdf-vm/asdf):

- [ ] Host rolling release `jar`s as well as "stable" releases somewhere (I can donate traffic and VPS for this)
- [ ] Track `jar`s released using "rolling release" strategy as well as releases that are manually marked as "stable"
- [ ] Allow to swap active `jar`s, effectively changing versions hither and thither

## Make a nix flake so that anyone on any Linux or mac os can build `jar`s with 0 overhead

The key feature of [nix](https://en.wikipedia.org/wiki/Nix_package_manager) is that it allows multiplexing the same piece of software, library, etc. For example, with `nix` you can have a particular version of JRE / JDK isolated just to your project.

### Immediate action points

- [x] Allow for `nix develop` with a [`flake.nix`](https://github.com/cognivore/xmage-devops/blob/main/flake.nix)

### Further work

- [ ] Allow to build and publish `jar`s with just `nix build`, without the developers needing to run `mvn package`

# How will it impact the community?

1. Even if the procedure will not be completely automated, it will still be possible for any contributor to make a release, and *crucially* for any community to use arbitrary commit, even unpublished, even if all the contributors are absent
2. It will be trivial to upgrade a server, since all that changes are packaged `jar`s. No more accidental config rewrites
3. Flexible trust: one can choose to trust some server's maintainer to pick correct `jar`s and just install whatever they advertise
4. No need to reinvent the wheel when it comes to redistributing Java for the end user, this part stays the same and it'll be virtually the only real role of launcher at first