Move GAPROOT out of package directory

[fingolfin]

Currently we create a symlink tree inside the GAP.jl package directory, inside PKDIR/gaproot/v1.6/ and so on (depending on the Julia version).

This is problematic in shared Julia installation where the GAP.jl package directory might be read-only. In general, the Julia folks would like to move to a system where package directories (at least for release versions) are read only. And I think this makes a lot of sense, too.

Fixing this should essentially "just" require adjusting

const GAPROOT = abspath(@__DIR__, "..", "gaproot", "v$(VERSION.major).$(VERSION.minor)")

in src/gap.jl to a different path. Ideally it should probably be using Scratch.jl.

(A secondary objective would be to also adjust build_JuliaInterface to build outside of the package directory; but this code should normally only matter for dev builds where the C sources were modified, so it's not important for now).

One concern lingers: the report motivating this issue was performed on Kaiserslautern computer servers, with a shared Oscar install, with a custom Julia "depot". I should verify that Scratch.jl works correctly in that setup, i.e., it returns a path in the user's depot (in particular: it must be writable).

CC @fieker @ThomasBreuer

[ThomasBreuer]

If I understand the idea behind Scratch.jl right then one gets the path to the package's scratch space only at runtime, via a call in the __init__ function.
The current GAPROOT is used during precompilation. Is this idea compatible with Scratch.jl?

[fingolfin]

Precompilation isn't really an issue, we can query the scratch path at any time, including precompilation time; we just shouldn't store it!

Anyway, I tried to implement this now, but run into some problems and then found these, which made me remember why I gave up on this the last time:

• Guidance on avoiding race conditions when multiple jobs try to access and (re)generate the same scratch space JuliaPackaging/Scratch.jl#26
• Why to avoid baking absolute paths into our precompiled files? JuliaPackaging/Scratch.jl#20
• (for kickers also Reference section link broken JuliaPackaging/Scratch.jl#25)

I am now wondering whether I should simply create a fresh GAPROOT each time GAP.jl starts, they don't take up much space and are quick to create... sigh.