Directory reorg: move code into redo/, generate binaries in bin/.

It's time to start preparing for a version of redo that doesn't work
unless we build it first (because it will rely on C modules, and
eventually be rewritten in C altogether).

To get rolling, remove the old-style symlinks to the main programs, and
rename those programs from redo-*.py to redo/cmd_*.py.  We'll also move
all library functions into the redo/ dir, which is a more python-style
naming convention.

Previously, install.do was generating wrappers for installing in
/usr/bin, which extend sys.path and then import+run the right file.
This made "installed" redo work quite differently from running redo
inside its source tree.  Instead, let's always generate the wrappers in
bin/, and not make anything executable except those wrappers.

Since we're generating wrappers anyway, let's actually auto-detect the
right version of python for the running system; distros can't seem to
agree on what to call their python2 binaries (sigh). We'll fill in the
right #! shebang lines.  Since we're doing that, we can stop using
/usr/bin/env, which will a) make things slightly faster, and b) let us
use "python -S", which tells python not to load a bunch of extra crap
we're not using, thus improving startup times.

Annoyingly, we now have to build redo using minimal/do, then run the
tests using bin/redo.  To make this less annoying, we add a toplevel
./do script that knows the right steps, and a Makefile (whee!) for
people who are used to typing 'make' and 'make test' and 'make clean'.

docs/redo-log.md

@@ -0,0 +1,83 @@
+# NAME
+
+redo-log - display log messages from previous builds
+
+# SYNOPSIS
+
+redo-log [options...] [targets...]
+
+
+# DESCRIPTION
+
+When redo runs, it captures the standard error (stderr) output from the
+build activity for each target, and saves it for later.  When a target is
+rebuilt, the new logs replace the old logs for that target.  redo-log
+prints the log output for any set of targets.
+
+# OPTIONS
+
+-r, --recursive
+:   if the requested targets cause any dependencies to be built, recursively
+    show the logs from those dependencies as well.  (And if those
+    dependencies build further dependencies, also show those logs, and so on.)
+
+-u, --unchanged
+:   show messages even for dependencies that were unchanged (did not need to be
+    rebuilt).  To do this, we show the logs for the *most recent* build of
+    each affected dependency.  Usually this is used with `-r`.
+
+-f, --follow
+:   if a build is currently running for any of the requested targets or
+    their dependencies, follow the logs (like `tail -f`) until the build
+    finishes.
+
+--no-details
+:   display *only* the messages from redo itself, not the other messages
+    produced by build scripts.  Generally this gives you a list of which
+    targets were built, but not detailed logs, warnings, or errors.
+
+--no-status
+:   don't display the running build status at the bottom of the screen. 
+    (Unless this option is specified, the status line will be enabled
+    if using --follow, if stderr is a terminal.)  If stderr is *not* a
+    terminal, you can force enable the status line using --status.
+
+--no-pretty
+:   display "raw" redo log lines (@@REDO events) rather than using a
+    human-readable format.  The default is --pretty.
+
+--no-color
+:   when using --pretty and writing to a terminal, colorize the output to
+    make results stand out more clearly.  If not writing to a terminal, you
+    can use --color to force colorized output.
+
+--debug-locks
+:   print messages about acquiring, releasing, and waiting
+    on locks.  Because redo can be highly parallelized,
+    one instance may end up waiting for a target to be
+    built by some other instance before it can continue. 
+    If you suspect this is causing troubles, use this
+    option to see which instance is waiting and when.
+    
+--debug-pids
+:   add the process id of the particular redo instance to each
+    output message.  This makes it easier to figure out
+    which sub-instance of redo is doing what.
+
+
+# REDO
+
+Part of the `redo`(1) suite.
+    
+# CREDITS
+
+The original concept for `redo` was created by D. J.
+Bernstein and documented on his web site
+(http://cr.yp.to/redo.html).  This independent implementation
+was created by Avery Pennarun and you can find its source
+code at http://github.com/apenwarr/redo.
+
+
+# SEE ALSO
+
+`redo`(1)