lbmk: don't handle TMPDIR directly

lbmk creates TMPDIR as /tmp/xbmk_*, but it's theoretically
possible that something could re-export it by mistake.

this change retains the same initialisation, but further
use is now via a new variable "xbmktmp", that stores the
value of TMPDIR upon lbmk's initialisation of it.

this reduces the chance of such a bug in the future, as
described above, so it is a preemptive/preventative fix.

Signed-off-by: Leah Rowe <leah@libreboot.org>

include/lib.sh

@@ -50,7 +50,7 @@ chkvars()
 }
 
 eval "`setvars "" _nogit board reinstall versiondate aur_notice configdir \
-    datadir version relname`"
+    datadir version relname xbmktmp`"
 
 for fv in version versiondate; do
 	eval "[ ! -f \".$fv\" ] || read -r $fv < \".$fv\" || :"
@@ -127,6 +127,7 @@ if [ -z "${TMPDIR+x}" ]; then
 	[ -f "lock" ] && $err "$xbmkpwd/lock exists. Is a build running?"
 	export TMPDIR="/tmp"
 	export TMPDIR="$(mktemp -d -t xbmk_XXXXXXXX)"
+	xbmktmp="$TMPDIR"
 	touch lock || $err "cannot create 'lock' file"
 	x_ rm -Rf "$XBMK_CACHE/xbmkpath" "$XBMK_CACHE/gnupath"
 	x_ mkdir -p "$XBMK_CACHE/gnupath" "$XBMK_CACHE/xbmkpath"
@@ -144,6 +145,7 @@ if [ -z "${TMPDIR+x}" ]; then
 	rm -f lock || xbmk_rval=1
 	exit $xbmk_rval
 fi
+xbmktmp="$TMPDIR"
 
 # if "y": a coreboot target won't be built if target.cfg says release="n"
 # (this is used to exclude certain build targets from releases)