debian/rules build: describe dependencies between targets in more detail

debian/rules build: describe dependencies between targets in more detail

Tell debian/rules which files should trigger an autoreconf or
./configure run when modified.  This way, familiar processes like
build / modify / build and bisecting to find the source of a
regression will work without requiring a "debian/rules clean" so
often.

The build goes through the following stages (as implied by
dependencies).

 1. autotools input (e.g., configure.ac) is transformed by autoreconf
    to
 2. autoreconf output (e.g., configure, Makefile.in) which is
    transformed by configure with the help of templates like
    Doxyfile.in to
 3. basic build files (as represented by $(builddir)/Makefile) that
    are used to build
 4. xz, xzdec, wrapper scripts, and API documentation that are needed
    to produce
 5. successful test results (as represented by the stamp files
    debian/test-*-stamp)

Details:

 - at step (1), the system autotools files are very relevant and not
   reflected in dependencies.  Use "touch configure.ac" if you want to
   force a rebuild of the configure script.

 - during step (2), make only pays attention to the timestamp of the
   resulting toplevel Makefile, even though that is certainly not the
   only file being written.  If the configure script is interrupted
   writing the Makefile and before writing other files, the result
   might be confusing.

 - there is no timestamp associated to the result of step (3), so
   "make -C $(builddir)" is always run to check if any files need to
   be rebuilt (which is exactly what one would want to happen ---
   good!).

 - as a consequence, "make" does not know whether results from (4)
   (the test suite) are stale.  So we declare that if the test suite
   has ever run all the way through then that’s good enough, using
   make’s order-only prerequisite (“|”) feature.

After this patch, as a nice side effect, debian/rules knows enough to
build xzdec and standard xz in parallel.