Use host user for Docker builds

[hkjn]

By using the same user inside the container as on the host, we avoid
issues with the host user lacking the privileges to e.g remove files
under build/, which are bind-mounted from the host into the container.

Before this change, those files would run as the super-user (id -u of
0), which caused the issues mentioned above, specifically on Gitlab,
where subsequent test runners would find themselves unable to clean up
the build/ artifacts from prior builds.

The unfortunate edge case here is for users that (wisely!) require
sudo to run docker commands, there is no way for the Makefile
to deduce what their non-privileged user's id is. Those users
need to either deal with the super-user (id 0, commonly root)
owning the files under build/, or to explicitly specify their
non-privileged user's id when calling make commands:

sudo make BUILDER_UID=$(id -u)

[hkjn]

This PR can be tested by removing the build/ directory entirely, then restoring the build/README.md from the repo (i.e bring the repo back to a clean state), then doing a build, and observing that the files are owned by the non-privileged user:

$ sudo rm -rf build/
$ git checkout -- build/README.md
$ sudo make docker-build-go BUILDER_UID=$(id -u)
$ ls -hsal build/
total 14M
4.0K drwxr-xr-x  2 user user 4.0K Jun 25 17:45 .
4.0K drwxr-xr-x 13 user user 4.0K Jun 25 17:50 ..
8.6M -rwxr-xr-x  1 user user 8.6M Jun 25 17:45 base-middleware
2.3M -rwxr-xr-x  1 user user 2.3M Jun 25 17:45 bbbfancontrol
4.0K -rw-r--r--  1 user user  227 Jun 25 17:45 bbbfancontrol.service
2.5M -rwxr-xr-x  1 user user 2.5M Jun 25 17:45 bbbsupervisor
4.0K -rw-r--r--  1 user user  194 Jun 25 17:45 bbbsupervisor.service
4.0K -rw-r--r--  1 user user  167 Jun 25 17:45 README.md
``

[Stadicus]

utACK 736aa3d

[hkjn]

This commit actually introduced a regression, where if users have sudo required to run docker commands, their build will fail on this line. I've sent #99 to revert this commit for now, as we figure out the best path forward.