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-always.md

@@ -0,0 +1,49 @@
+# NAME
+
+redo-always - mark the current target as always needing to be rebuilt
+
+# SYNOPSIS
+
+redo-always
+
+
+# DESCRIPTION
+
+Normally redo-always is run from a .do file that has been
+executed by `redo`(1).  See `redo`(1) for more details.
+
+redo-always takes no parameters.  It simply adds an
+'impossible' dependency to the current target, which
+ensures that the target will always be rebuilt if anyone
+runs `redo-ifchange targetname`.
+
+Because of the way redo works, `redo-ifchange targetname`
+will only rebuild `targetname` once per session.  So if
+multiple targets depend on *targetname* and *targetname*
+has called redo-always, only the first target will cause it
+to be rebuilt.  If the build cycle completes and a new one
+begins, it will be rebuilt exactly one more time.
+
+Normally, any target that depends (directly or indirectly)
+on a sub-target that has called redo-always will also
+always need to rebuild, since one of its dependencies will
+always be out of date.  To avoid this problem, redo-always is
+usually used along with `redo-stamp`(1).
+
+
+# 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), `redo-ifcreate`(1), `redo-ifchange`(1), `redo-stamp`(1)