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/FAQInterop.md

@@ -0,0 +1,55 @@
+# Is redo compatible with autoconf?
+
+Yes.  You don't have to do anything special, other than the above note about
+declaring dependencies on config.h, which is no worse than what you would
+have to do with make.
+
+
+# Is redo compatible with automake?
+
+Hells no.  You can thank me later.  But see next question.
+
+
+# Is redo compatible with make?
+
+Yes.  If you have an existing Makefile (for example, in one of your
+subprojects), you can just call make from a .do script to build that
+subproject.
+
+In a file called myproject.stamp.do:
+
+	redo-ifchange $(find myproject -name '*.[ch]')
+	make -C myproject all
+
+So, to amend our answer to the previous question, you *can* use
+automake-generated Makefiles as part of your redo-based project.
+
+
+# Is redo -j compatible with make -j?
+
+Yes!  redo implements the same jobserver protocol as GNU make, which means
+that redo running under make -j, or make running under redo -j, will do the
+right thing.  Thus, it's safe to mix-and-match redo and make in a recursive
+build system.
+
+Just make sure you declare your dependencies correctly;
+redo won't know all the specific dependencies included in
+your Makefile, and make won't know your redo dependencies,
+of course.
+
+One way of cheating is to just have your make.do script
+depend on *all* the source files of a subproject, like
+this:
+
+	make -C subproject all
+	find subproject -name '*.[ch]' | xargs redo-ifchange
+
+Now if any of the .c or .h files in subproject are changed,
+your make.do will run, which calls into the subproject to
+rebuild anything that might be needed.  Worst case, if the
+dependencies are too generous, we end up calling 'make all'
+more often than necessary.  But 'make all' probably runs
+pretty fast when there's nothing to do, so that's not so
+bad.
+
+