Add directory field to dep. graph nodes

This is a first, easy, step towards having Holmake work over multiple
directories at once.

Allow an indication of side-products of theory builds

Basically, write something like

foo: *theorynameScript.sml

to indicate that foo will be built when the theory theoryname is
built. As part of the process, provide much better testing of the
parallel execution of multiple target rules and completely change the
way these are handled.

In particular, the dependency graph that Holmake maintains now does
not have multiple targets for a single node, but instead makes sure
that when a command is executed for a single target, all nodes that
would execute the same command are considered to be running at the
same time, and get the same success/failure status when the command
finishes.

Needs documentation, but is progress with Github issue #429

Rebuild .uo and .ui files without forcing unnecessary extra work

This is by analogy with what has already been attempted for heaps, and
is progress with github issue #105.

Also fix a bug with the heap handling if the heap was in a
directory with script-files (not the case with the heaps in HOL/src):
the dependency graph built for the directory spotted that there was a
dependency from the heap to the script files, and even though the
heap's time-stamp was set appropriately, the existence of the link in
the graph meant that the rest of the graph got executed.

The fix for this (in both the case of the heap and the .uo/.ui file)
is for execution of graph nodes to check at the time the node is made
ready to execute if the target really does need to be redone (by
examining time-stamps). Then, the rebuild can be skipped even though
the initial analysis thought it was going to have to happen.

Future work:
- For the moment, both build and Holmake rely on having a particular
environment variable set to enable this option. I will augment
and/or replace this with command-line options. (The buildheap
program needs to retain this use of the environment variable though
because neither Holmake nor build control how that program is
called; instead this program is called by the user via
Holmakefiles.)
- Build needs to take an option to clean a HOL installation of its
heaps and ui/uo files. I don't know how to automatically identify
the heaps, but could just purge those that are identified as such in
Holmakefiles.

Enable multiplexed builds for Poly/ML

Output is horrendous at the moment

Make dep. graph store single commands per node

This is something of a reversal of 8f7f1c9; but there I was worried
about smashing multiple commands into a single string, which is clearly
still a bad thing to have happen. The problem with having multiple
commands in a single node is that a multiplexing implementation has to
execute them as an atomic block, which I don't like.

Make dep graph record file-name in dependency link

Nodes in the graph are commands that may build multiple targets at once.
Nonetheless, other nodes may only depend on one of those targets, so we
can record this on the arc from the target to the dependency.

Make dep-graphs store commands as lists of strings

This will make it easier to extract and act on leading indicators such
as @ and - on each line. If a line is

-command

then it could be passed to the shell as command ; true. If the command
has the leading @, then that line shouldn't be echoed to the shell. In
a parallelised context, I'm not sure that anything much should be echoed
to the user anyway.

Previously, I had Holmake concatenate the lines from the Holmakefile
with intervening semicolons, which would just make extracting the @ and
- characters that much harder.

Fix dep-graph's handling of rules with >1 target

Now such rules (including the implicit/built-in rule that builds
<n>Theory.sig and <n>Theory.sml from one invocation of a script file),
only generate one node in the dependency graph.

Actually, the code will treat

foo: deps
command

bar: deps
command

as if they were written

foo bar: deps
command

because the former is what the latter expands into.

Implement a -n option for Holmake

This uses the new dependency graph technology. It doesn't look
particularly pretty at the moment, but

Holmake -n -q

should be useful. (The -q suppresses useless info about automatic
dependency analysis.)

Closes #283

Implement dependency graph type for Holmake

This should feed into process-multiplexing for the planned -j feature.
It may even be possible to get something reasonable happening here in
Moscow ML. Creating the dependency graph should also allow
implementation of a -n option (see github issue #283).