Use FHS-style layout #46

e.g. rename conf to etc.

I'm not sure what we should do about nonfree/code.

e.g. we could have a parallel layout with etc, share, var, nonfree/share and nonfree/var?

We also need to ensure directories are created before we try to write to them.

Rough plan:

bin/lib - from the Gradle distribution plugin
etc - config files
share/deob-map/*.yaml - deobfuscator maps (fine to use share as they're only written at build time)
share/doc - documentation
nonfree/lib/{jaggl.pack200,loader.jar,...} - original client code
- Debatable whether this should be in lib or share (as it's arch-indepedent), but using lib for jar files is consistent with the Gradle distribution plugin.
nonfree/var/cache/bundle - bundler output directory
- The FHS doesn't say much about whether it's safe to delete stuff in /var/cache while a program is running. If it is supposed to be safe, this should go in lib instead. I suspect most programs would fail though.

TBD: deobfuscator .jar file output. This might ultimately disappear if we combine the deobfuscator and decompiler into a single program.

Some probable future locations:

nonfree/share/cache - cache
nonfree/share/location-keys - XTEA keys
var/lib/players - flat file player data

Should the README/LICENSE/DCO files be moved into share/doc or remain in the root? I'm inclined to leave them in the root at the moment, given the importance of the README. This would also mirror the repo layout, and the README/LICENSE need to be in the root at least (for Gitea to auto-detect them).

I think /var/cache is okay for the deob output too, given it can be re-generated. I briefly considered /var/spool (given it's only used to hold data between the deob/decompiler runs) but the FHS says explicitly it shouldn't be used for data that can be re-generated.

Completed a while ago