resource_rewriting: compute hashes even for non-dep rewritable files

This is harmless and may be useful to resource_rewriting users.
Rewritable files were already being scanned (for links) and are
typically not many-megabyte files,
so hashing them shouldn't take excessive time.
resource_rewriting: assert that a text serialization is correct

TODO fixed.
Filenames containing newlines are technically legal but they
break one-filename-per-line and aren't useful enough to support
them here.
Make buildsystem more robust to odd old cached builds
resource_rewriting: make cached metadata filenames have extensions

This makes it less confusing to look at those dirs in the shell.
It also will make it possible for a directory that has contents
to have metadata itself too.

Downside/bug: directories named *.{deps,hash,name} next to a
file or directory named * will have problems.
resource_rewriting: explicitly store deps of referenced files without deps

This simplifies the code somewhat.
Make "no newlines in filenames" check more complete.

Rationale:
We write path-set files in text-mode which means Python
transforms between \n and \r\n on some platforms.

(My code would likely still fail to work on Windows for
other reasons like containing symlinks, because I don't
care about Windows for this personal project enough to
forgo useful features.)
fix make_transitive option

The code had been buggy when
  always_include_base_case = False, multiple_base_cases = True
remove bitrotted Apache-httpd support
refactor
refactor: don't serve unused css/js/any rewritable resource files

This patch separates resource_rewriting's concepts of which files
are rewritable and which files the user is planning to serve as
non-resource files.
resource_rewriting: include resource_rewriting.py in file hashes

This increases robustness.  It helps prevent two different file
contents from getting the same hash, which happened to me a couple
times while changing resource_rewriting, in ways that I'm not
100% confident would never apply to production.  The cost is that
hashes change on the occasions that I change resource_rewriting.py,
which is rarely.
resource_rewriting: refactor
resource_rewriting: delete old commented debug statement
resource_rewriting: refactor
resource_rewriting: support rewritable directories

`?rr` can now be put on a link to a directory,
in which case the directory is given
a unique name instead of the files in it.
This is useful for JavaScript that e.g. dynamically selects
    ("imgs/?rr" + "piece-" + piece_number + ".png")

The directory's unique name is based on the contents of
everything in it and the things they depend on.  The
unique path of each file in it is only unique by dint of
the directory's renaming.  Unfortunately, JavaScript
[doesn't come](https://stackoverflow.com/questions/2676178/joining-relative-urls)
[with correct](http://code.google.com/p/js-uri/)
[URL joining](https://stackoverflow.com/questions/10565624/completing-relative-url-to-current-webpage),
so `("imgs/?rr" + ...)` won't trivially work without
resource-rewriting the way `"some-image.png?rr"` does.

Another small downside: every file under such directories
will be served as a resource, even if it's not used as a
resource, because it's not trivially clear *which* files
under the directory are accessed by JavaScript in this way.
So try to put the files you're accessing this way in their
own subdirectory.
Stop using myglob.py

It was only used once, and it's better to reduce the amount of
code (and concepts) in a single project.
Move myglob.py to unused/ now that it's unused.
remove out-of-date comments
rrify.py: make it not have to be run from a particular current directory
Make `rrify.py` more friendly if run with e.g. --help