Local build automation for sharing results

during a conversation between @ma1 and myself we dared to dream of even more helpful scripts, and I mentioned I'd played with more build automation and result reporting into threats via APIs (https://git.openprivacy.ca/cwtch.im/cwtch-ui/pulls/988#issuecomment-20781 and https://git.openprivacy.ca/openprivacy/drone-gogs/src/branch/main/gogs-notify)

this came from a building saying their build wasn't done but they were off to sleep meaning we'd have to wait a lot of a day to find out how it went even if it concluded soon. the proposal is pretty simple:

• add a new Makefile target start-gpg-agent that just actives gpg so the user is prompted for a password before the build runs incase it is not unlocked
• update build templates in git lab to recommend make start-gpg-agent && make torbrowser-release && make torbrowser-incrementals-release && make torbrowser-upload-sha256sums-release

as one quick step and then a second step:

• extend the upload-sha256sums-release step in tbb to accept a gitlab api token from rbm.local.conf (like the vpn project is already requiring in local.properties so gradle can fetch our latest internal CI build of onionmasq's .aar) and post the link and results to the thread which would have to be passed in as an argument to that step (or at least the issue number)

discussion about this step:

if we're putting a commenting api token in rbm.local.conf, do we want to get really ambitious to make some kind of triggerable flag (env var?) so that each of the build steps could also use it to report a build failure? off be default but if like TBB_BUILD_ISSUE is defined, the torbrowser-release and torbrowser-incrementals-release could be extended to also post about a failure