runtime,dag: drop the DAG rebuild step

It looks like we can get away without it: just leave FinderNodes as-is
in the graph, and expand wildcards when expanding actions, i.e. as
late as possible.

This means I had to implement Signature() and Exists() in FinderNode.
As soon as one of them *or* Expand() is called, we'll expand the
wildcard -- so it'll probably happen a little sooner than running
actions, but not much.

This also meant we could get rid of DAG.FindRelevantNodes().
types: factor ExpandString() out of FuString.Expand()
dag: add ListNode type (unused so far, but should come in handy soon)

I have a couple of use cases in mind:

  1) <*.c> + <*.h> should evaluate to a single ListNode containing two
     FinderNodes, rather than a FuList with two FinderNodes -- then it
     can be added to the DAG as a single object

  2) imagine this script:
       dirs = <src/*>
       dirs.exclude("skipme")
       src = <$dirs/*.c>
       "app": src {
           "cc -o $TARGET $SOURCE"
       }

     It should be possible for src to be a ListNode whose size isn't
     known until runtime, when we expand the FinderNode in dirs. src
     can be added to the DAG as a single node, and expanded
     appropriately in the build action.
dag: use ListNode for the result of FinderNode + anything

Only works for limited values of "anything". In particular:
  * any other Node is fine
  * FuString is automatically promoted to FileNode
  * FuList of Node or FuString works too
But any other type will be rejected, because ListNode should only
contain other Nodes.
dag,types: formally distinguish DAG expansion from action expansion

There are two motivating use cases:

  1) filefinders with variable references, e.g.
       src = <$dir/**/*.c>
     need to expand $dir before we walk the DAG, in fact before
     matching targets -- the user isn't going to ask for literal
     '$dir', but for the directory that $dir expands to. But we
     don't want to expand the wildcard at the same time, since that
     should happen later.

  2) a build rule like
       "$dir/myapp": "$dir/main.c" {
           ...
       }
     again we want to expand $dir in the two FileNodes created there,
     but we don't want to expand all wildcards at the same time --
     so we need to distinguish the two types of expansion

The solution is to distinguish expansion that happens in the DAG from
expansion that happens in an action. DAG expansion manifests as
Node.NodeExpand(), so it only has to be implemented by Node types --
which makes sense, since it only affects nodes in the DAG. It's
responsible for turning strings like "$dir/**/*.c" or "$dir/myapp"
into something that can be used for target matching:
"src/myapp/**/*.c" or "src/myapp/myapp", say. DAG expansion happens
after the main phase completes, but before the build starts running.
The other expansion is action expansion, which manifests as
FuObject.ActionExpand(), i.e. every Fubsy type has to support it. It
also does variable expansion, because command strings often contain
variables ("$CC $CFLAGS ..."), but they'll never appear as DAG nodes.
But it also takes care of expanding wildcards -- so this is where a
FinderNode will be replaced by the list of matching filenames.
build script: first crack at self-hosting, i.e. a fubsy build script for fubsy

Doesn't work yet! This reveals several bugs and missing features. I've
fixed one (in 4887361f3414), but there's lots more work to be done
before fubsy is self-hosting.
dag: add ExpandNodes(), so filenames with embedded variables are expanded

This will make it possible to have build rules like
  "$src/parser.c": "$src/parser.y"
or
  "$out/mytool": <$src/**/*.c>

More concretely, it means that we're a lot closer to self-hosting: the
main.fubsy now works to build golex, gocov, and the Fubsy lexer and
parser. Woo-hoo!
merge