Locking is good to have for all the user's databases, not just ctags.

We already have this with ctags, should have it for gtags too.

This argument is a path where tags should go (ie g:gutentags_cache_dir,
or the directory to scan if not set) and would need to be quoted if it
had spaces or other characters meaningful to the shell.  The variable
gets assessed by 'eval' before being used to invoke gtags, so we want to
embed the escapes within the string.

While we do this for correctness, note that unix cscope cannot handle
directories with spaces in the path to the tags file, because it puts
the directory name in the database and uses spaces to delimit records in
the first line (the filename, and also dash-prefixed options cscope had
when constructing the database, so there's no way to know for sure where
the filename ends).

Vim cannot handle spaces either.  The limitation does not exist for
gtags, but vim's ":cs add" (src/if_cscope.c::cs_add()), typically
invoked from gutentags_plus, does not handle spaces correctly itself.
It uses spaces in the arguments to break apart into significant
subwords, to distinguish other arguments to ':cs'.

Lastly the cscope command used by vim in src/if_cscope.c
cs_create_connection() does not properly quote the filename when it
passes to /bin/sh -c "exec cscope -dl -f %s" so that wouldn't handle
spaces either.

For now we can live with the limitation that we can't ever use cscope
functionality in paths with spaces in them.

The shell default is for clobber to be set, so "echo $$ > $LOCKFILE"
will succeed no matter how many times it's run.  In other words, this
wasn't acting as a lockfile at all, unless the user had set 'noclobber'
in their shell's non-interactive profile.

In each of these scripts, a trap exists that does cleanup, so the lock
files should get removed at script exit no matter what.  If the computer
crashed or lost power in between though, the stale lock file would be
left and have to be manually removed.  This is not unlike any other
stale lock file issue.

However we could check if the pid exists, since it's written to the
file.  That sounds invasive and non-portable... maybe later.

If we try to establish the lock first before EXIT trap is established,
we can exit without removing the lock file of the previous instance.
Otherwise we'll correctly exit, but then remove the temp file out from
under the already-running instance.  Next collision avoidance test will
pass and we'll clobber previous instance.