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.
add new dependency: bitbucket.org/ww/cabinet (cgo wrapper for Kyoto Cabinet)

(taken from upstream changeset ee876328069f)
db: add KyotoDB, a BuildDB implementation using Kyoto Cabinet

This required several additional changes that will be used for most persistent
implementations:
- add Close() method to the interface
- add binary encode()/decode() methods to BuildRecord (only useful for
  key/value stores)
db: improve error handling in KyotoDB
db: add a bit of debug logging to KyotoDB
runtime: use a real persistent database (KyotoDB) instead of DummyDB
db: fix broken key generation in KyotoDB
db: add Dump() to BuildDB interface (implement it in DummyDB, KyotoDB)
main: add fubsydebug (same binary, different name -- eg. with a symlink)

The idea is that it will provide multiple subcommands:
  fubsydebug CMD ...

The only command currently implemented is "dumpdb".
db: require OpenKyotoDB caller to explicitly specify read-write vs read-only

This means that fubsydebug won't accidentally create an empty database
if the user passes it an incorrect filename.
db: make OpenKyotoDB() take the exact filename, not the basename

This makes the UI for fubsydebug clearer: the user just specifies the
filename, no funny tricks required. But it probably needs we'll need a
small layer between runtime and Open*DB() to figure out which DB type
to open when we have multiple DB types available.
db: decode each node's BuildRecord in KyotoDB.Dump()
dag: implement FileNode.Signature()
dag: implement FileNode.Changed()

Now Fubsy is a genuine incremental build tool: it no longer thinks
that every file has changed every time!
doc: remove some obsolete notes now that incremental builds work