dag: add prune support to FinderNode
types,dag: add support for attribute lookup on values

So far, strings and lists have no attributes, so lookup always fails
-- would have to change FuString and FuList to structs for that, which
will be a bit of upheaval.

All Node types support attribute lookup, though -- but there are no
attributes defined yet.
dag: export NewFileNode() instead of newFileNode()
types,runtime: add support for finding and calling methods
runtime: make ActionNode constructor automatically add ':action'

This means users can use path-like node names without worrying about conflicts
with the filesystem.
runtime: export FileNode() constructor as a builtin
update to latest version of github.com/axw/gocov (upstream rev bcb74f1fa6b05c843cb7888551bc3ca4096ec473)
docs: describe how to get upstream rev number when updating dependencies
runtime,types: wrap function arguments up in a struct, passed as an interface

The trivial, obvious benefit is that declaring Fubsy functions as Go
functions is a lot simpler: they just take a single ArgSource
instance.

More subtly, this will make it possible for some functions to have
access to the Runtime and DAG objects -- specifically, anything
defined in 'fubsy/runtime' will. Methods/functions defined in other
packages won't have that access, because of Go's package cycle rule.
runtime: expose the Runtime object to all evaluate*() functions

Will be needed so we can have a builtin build() that constructs build
rules and adds them to the DAG, all of which requires access to Runtime.
runtime: make assign(), evaluate*() methods of *Runtime

They used to be standalone functions that were ignorant of Runtime.
Then they were standalone functions that all took a *Runtime as first
argument, and often used it directly. So making them methods of the
*Runtime is not a big leap.

This means that methods of *Runtime are split between two source
files: runtime.go and execute.go. Hmmmmm. Not sure how I feel about
that.
runtime: change node constructors to node factories

Calling FileNode() or ActionNode() twice with the same name now
returns the same object. Future *Node() functions must act the same
way!
dag: simplify DAG.Dump() output a bit: just use node.String()
types: change so String() returns quoted values; introduce ValueString()

At least for FuString, ValueString() replaces the old String(): it
returns a filename that can be opened, a command that can be run, etc.
String() returns a debugging-friendly value, using Fubsy syntax to
explain a value where possible. The rationale is that debug messages
(Printf() etc.) will use String() by default, and code that needs the
"true" value to interact with the system should know what it's doing
and use ValueString().
dag: make String() method of Node types more consistent with FuString

In particular, return the name in quotes. If you want the bare name,
use Name() (or ValueString(), which should be equivalent to Name()).
runtime: do not expand values in evaluateCall()

If we're calling functions in build rules, then it's appropriate to
ActionExpand() arguments. But functions can be called from any phase,
and evaluateCall() doesn't know which phase it's in. It will have to
rely on someone else to ActionExpand() each value in the build phase
-- NOT DONE YET!
runtime: expand function arguments when appropriate (from an action)

Actions should only run in the build phase, so it's fine to do
ActionExpand() from them. And it's consistent: CommandAction was
already responsible for expanding the command string, so it makes
sense for FunctionCallAction to be responsible for expanding function
args.

Fixes the regression introduced by fa1ec190cb9a.
runtime: (temporarily) remove support for keyword args

Since the parser doesn't handle them yet, it seems silly to waste time
making the runtime handle them.
runtime: add build() builtin for defining build rules

Of course you can already define build rules with the special syntax
for them. This is really intended for plugins, which can't be written
in Fubsy syntax; they'll need programmatic access to define build
rules. Supporting it in the DSL is optional, but seems like a nice
touch for completeness.