build: add database and start using it

- build package defines BuildDB interface
- new package db contains implementations
- currently only one implementation, DummyDB (in-memory,
  good enough for testing)

The only use of BuildDB so far is to detect if sources were added to a
particular target since the last build.
build: add test case for a new source on an existing target

This could not have worked without the addition of BuildDB in the
previous revision.
build: handle the case where a node's parent is removed

If you remove a source file, then the next build must rebuild anything
that formerly depended on it.
build: fix "is source changed?" check to reflect current target

This handles the following case:
  - full build
  - modify shared source S
  - build T1, one of the targets that depends on S
  - build T2, the other target that depends on S

Formerly, the third build (of T2) would incorrectly decide that S has
not changed, since we only considered whether S has changed since the
last build, period. But what really matters is whether S has changed
since it was last used to build T2. Getting this right means
Node.Changed() must compare old and new signature.

This case is also the rationale for why BuildDB stores a list of
(source, signature) pairs for each target.

This changeset (temporarily) breaks the --check-all option: for the
moment, we unconditionally check whether every node has changed, i.e.
--check-all defaults true (and there is no way to turn it off). This
will be fixed shortly.
build: restore the usefulness of --check-all

When inspecting a parent node that is itself an intermediate target,
avoid the expense of Node.Signature() by checking the signature stored
in the database the last time that node was built. This requires lots
of changes to the BuildDB interface and friends:
- rename SourceRecord to BuildRecord
- add "target signature" to BuildRecord
- rename most BuildRecord methods to more accurately describe what
  they do
- rename BuildDB methods similarly
log: define debug topics statically

This means we can detect and report bad topics on the command line and
automatically generate accurate help for the --debug option. It should
also be faster, since the constants are bit flags rather than strings.