The ultimate issue here was that we performed a
```
cat $( ... ) | sed '1d'
```
and if that inner block was empty, then `cat` reverted to waiting for user input. The
error also came up with non-specified build numbers, so we need to make sure that those
are also being fetched correctly.

The upshot is now `<module>_VERSION` will automatically fetch the correct build number;
the only potential downside is that if we have a newer version in `${E3_SITEMODS_PATH}`
in comparison to `${EPICS_MODULES}` (read: cellMods), then it won't pick that up. However,
this seems to be a pretty special corner case.

This is necessary for the following reason: the previous mechanism used an
eval/call combination that required SUBS and TMPS to be exported on a previous
pass through. This allowed us to use `vpath` for each specific file in order
to locate the correct source files.

In order to avoid that, we add two new ingredients:
* `VPATH` instead of `vpath`, since it allows us to have variables
  that are expanded later
* `.SECONDEXPANSION`, which allows a target (`db_internal`, in this case) to
  perform a second variable expansion at the _end_ of the pass through.

All of this is necessary because the typical module makefile looks like:
```
include driver.makefile

SUBS += ...
```
i.e. `SUBS` and `TMPS` are defined _after_ the inclusion of driver.makefile. If
we don't want to force a re-write of every single module makefile, we needed
to do some of the above changes.

In a dependency chain like B->A->C and also B->C where A needs a version
of C different than B the build should fail.
This commit adds this check during dependency treatment on the built
target.

This follows the same pattern as the .d files generated during compilation; the
.d files are generated as a side effect of generating the output file, and we
then include them all at build-time to register the correct dependencies. See
line 634 of driver.makefile.

This uses some general make tools, most notably "while" and "select" which come from
https://github.com/markpiffer/gmtt.git and which allow us to recursively parse the
.dep files in the given e3 installation. Broadly speaking, we start with all variables
of the form `%_DEP_VERSION` to determine the first line of dependent modules, and then
we ask them (using `fetch_deps`) what they depend on.

This seems to be a very specific, limited issue, affecting virtualbox VMs only. There appears to
be an issue with how append data is buffered and written to disk. You can see this with the
following commands:

```console
$ rm -f out.tmp && seq 1569 >> out.tmp && ls -l out.tmp
-rw-r--r-- 1 simonrose vagrant 8188 Feb 14 12:12 se.tmp
$ rm -f out.tmp && seq 1560 >> out.tmp && ls -l out.tmp
-rw-r--r-- 1 simonrose vagrant 8192 Feb 14 12:12 se.tmp
$ rm -f out.tmp && seq 9999 >> out.tmp && ls -l out.tmp
-rw-r--r-- 1 simonrose vagrant 8192 Feb 14 12:12 se.tmp
```
Note that the last two files are the same size, when they should clearly be quite different. If we
remove the `>>` and replace it with a `>`, then all works correctly:
```console
$ rm -f out.tmp && seq 9999 > out.tmp && ls -l out.tmp
-rw-r--r-- 1 simonrose vagrant 48888 Feb 14 13:14 out.tmp
```
Note the file size in this case.