Test install scripts in CI

[ISSOtm]

Following up on #1931 (comment): we're currently running make install and cmake --install in CI, but not really checking that they do what they're supposed to.

Two options:

• Just stop doing it.
• Try to assert that installation does work, e.g. command -v rgbasm and MANPAGER=head man 5 rgbasm?

[Rangi42]

The Makefile's install target is nontrivial/manual enough that I think it's worth testing. Likewise for cmake --install, since it can be harder to tell what that would even do (compared to the Makefile's straightforward list of commands).

[Rangi42]

Related to this: we have two places that spell out the individual install commands, the Makefile itself for its install: target, and the .github/scripts/install.sh script. I'd like to get rid of the install.sh script.

The Makefile's commands have some advantages over the script: they let you configure the directories where things go, and they use the man pages already in the man/ subdirectory, no need to copy them into the top level.

The Dockerfile is the only place that actually runs install.sh (which is a bit odd given that it's in the .github directory, meant for GitHub Actions workflow internals). That can easily be replaced by running make install.

The install.sh script is also used in two places, create-release-artifacts.yml and the Dockerfile, to bundle it with the binaries and man pages into rgbds-linux-x86_64.tar.xz. This makes sense, but we don't have to keep the install.sh file -- it can be generated with cat <(echo '#!/usr/bin/env bash') <(make -n install).

(If we want to keep the possibility of the binaries and man pages all existing in the same directory level to be installed, then I'd rather parameterize that in the Makefile too, e.g. define mansrcdir := man, change references like man/rgbasm.1 to ${mansrcdir}/rgbasm.1, and then generate the install script with make -n install mansrcdir=..)

[ISSOtm]

The other option is to have a script that gets configured by CMake (we especially have the GNUInstallDirs package) and included in the generated package automatically. This would play even nicer if we end up switching all of our packaging to CPack.