runner: give builds a home that outlives the build !298

A regression I introduced in !289 and caught watching it run on bay1.

Setting HOME to the workspace kept a build away from the runner's dotfiles, which was the point, but run() does defer os.RemoveAll(dir) on that workspace. So every tool cache under HOME died with each build: the Go module cache — visible as a screen of go: downloading … on every job — and the sonar scanner, which .gitbay/ci.yml explicitly caches "rather than re-downloading ~50MB per build". Both were previously under /var/lib/gitbay-runner, the runner's home, which is exactly where a build should not be reading.

HOME is now <workdir>/home: persistent across builds, and still not the runner's own home. Both properties, neither at the other's expense.

It is shared by every build on the runner, so a step can poison a cache another repository's build will read. That is no more than a step can already do as this user — the wiki's Threat-Model says so — and is what container isolation (#144) is for; -repos is the control until then. Said out loud in the code and in the threat model rather than left to be discovered.

TestStepEnvHomeIsNotTheWorkspace fails if HOME ever points at a build-<id> directory again.

This may also explain a go vet ./... failure on !296 that does not reproduce locally: the first cold-cache build after the deploy died resolving a transitive module. I have not confirmed that link, and am not claiming it as fixed.

Stacked on !297.

Ref #144