Fix an UnboundLocalError if a compiler fails.

Pull request 531, among many other things, includes a similar fix for the use
of `stdout` before it's been assigned. That implementation is a nicer read, so
I've switched over to it.

Depending on where an exception is raised inside a compiler's
`execute_command`, the `stdout` variable may not be assigned. In this case, the
finally handler would fail with an `UnboundLocalError`, hiding the true cause
of the exception. This change adds a new variable, `stdout_name`, which is
populated once we've actually created the file. After this, the `CompilerError`
is successfully raised with the contents of the true error.

Don't filter out "missing" files in the glob stage.

The aforementioned change to `glob` surfaced a couple errors in the unit tests:

1. `test_glob_literal` was still testing the old behavior of non-existing paths
   being filtered out.
2. The post-process tests (`test_post_process_dry_run` and `test_post_process`)
   were now failing because post-process was being run without first collecting
   the media. This is a case where non-existing files were previously being
   filtered out silently but now cause an error. Running the collection stage
   before testing `post_process.

Fix compatibility with Django < 1.8

Commit bd6b9d89 dramatically changed the way that files are loaded, and had the
side-effect of filtering out any files which were sourced by finders outside of
the main `STATICFILES_DIRS`.

In the case I'm trying to address, we have an extension framework (in Review
Board and Djblets) which can load static media from third-party packages which
are activated at runtime. This media is loaded by instantiating
`StylesheetNode` and `JavascriptNode` from `pipeline.templatetags` in
combination with a special finder. Because django-pipeline no longer uses
finders before the compile stage, calling `storage.exists` (via
`Package.sources` -> `glob`) silently filters these out.

Inside `glob`, I agree that it's useful to test existence when trying to expand
`*` or `?`, but when the path is just a normal filename, it should be safe to
assume that the user knows what they're doing. This causes the paths to be
emitted into the rendered template whether or not `staticfiles_storage` claims
they exist, and anything which the configured staticfiles finders can't locate
will surface as a 404 rather than being silently eaten.

The 1.6.1 release added a dependency on the `setting_changed` signal. In Django
releases prior to 1.8, this signal is located in the `django.test.signals`
module, and in 1.8, an alias was added in `django.core.signals`.

This change adds a fallback import to restore compatibility with older versions
for applications which cannot (yet) migrate to the newer Djangos. It has been
tested against Django 1.6.11 and 1.8.9.

add doc for deactivate collector in develop

adding the ability to disable the collector in develop

This reverts commit 7520777f.

This reverts commit f05fe5e5.

Names on disk and config files should not have to be safe for shells to
interpret. As close to possible, we should take literals and give literals to
the OS kernel to operate on directly. For filename globs, it is our
responsiblility to expand them, and if we had no problem with backwards
compatibility, we would insist config files' SCRIPT_ARGUMENTS parameters are
tuples of discrete values. Delegating those to a shell breaks clear boundaries
of interpreetation and will always be prone to errors, oversight, and
incompatibility.

So, now, we never take names that are unsafe and try to make then safe for a
shell, because we don't need a shell.

This fixes #444, which had problems with Windows paths being insensible to the
crazy quoting we hoped would make a filename safe for a shell.

This fixes #494, which had a compiler-attempt stdout captured as part of a
string interpreted by a shell. When the compiler didn't exist, that shell
expression STILL created empty files, and the pipeline thenafter served an
empty file as if it were real compiler output.

Fix literal markup for settings

Remove unnecessary indentation

To avoid wrapping text in `<blockquote>` tags.

In headings and one non-heading. This is probably a leftover
after some semi-automated way of removing that `PIPELINE_` prefix.