New method for module installation

[vandenman]

Fixes https://github.com/jasp-stats/INTERNAL-jasp/issues/1887 part of https://github.com/jasp-stats/INTERNAL-jasp/issues/1782

See also https://github.com/jasp-stats/jaspBase/pull/88

The new installation procedure works like this in a nutshell.

1. After installing jaspBase, we always write all commit/ hash information for all modules to build/R/library/jaspBase/commitHashes.rds. This is mainly for performance reasons because otherwise, we need to recompute the hashes on the go when installing modules (and we'd be doing this repeatedly). There are fallbacks in place for when this object is missing. These hashes are the same as we currently use in the xxx_md5sums.rds files.

2. To install a module, we create an renv lockfile with the local paths to the checked out jasp modules and the hashes in commitHashes.rds. This tells renv to install those specific paths and after installation this lockfile is written to build/Modules/jaspDescriptives/renv.lock. We do not use the hashes renv creates because those only look at the DESCRIPTION file to create a hash (and we rarely update that).

3. The next time jasp is built, we compare the hashes in commitHashes.rds, which is always regenerated after running install-jaspBase.R, to the hashes in the lockfile. If there is a difference, we update the lockfile with the new hashes and tell renv to restore the lockfile (which should only update changed packages in the lockfile, not all packages).

For example, the new behavior is the following:

1. build
2. change something meaningless in jaspGraphs (or jaspBase).
3. the first module will rebuild jaspGraphs (and only jaspGraphs).
4. all subsequent modules will update their symlink of jaspGraphs to the new version (in general, all module libraries now update their jasp module dependencies to the latest on-disk version).

In addition, this PR adds two environment variables.

The environment variable JASP_UPDATE_R_DEPENDENCIES implements an updating mechanism, so that the existing packages in a module can be updated without reinstalling the entire thing. By default, this happens once a week but this can be adjusted (see code).

The environment variable JASP_RECORD_LOCKFILE controls how the lockfile references jasp modules.

• If set to "all" then it acts just like renv would and should ensures that a module environment can be reinstalled on a different computer (although I haven't tested this thoroughly).
• If set to "localJasp" then references to jasp modules use paths and hashes specific to the local system, so that's not reproducible (but has benefits when building).

Note that I left all original code for installing modules in place because dynamic modules still use that code (for now).

This needs to be tested extensively (I only tested on Linux :penguin:)