Add a view for collecting static files before serving them.

In a Django development setup, it's common to have a /static/ URL set up
to serve static media to the browser upon request. That's usually set to
either serve out of a specific directory or out of any configured
finders. However, the former doesn't guarantee any referenced files were
collected first, and the latter only considers source files (for the
purposes of timestamp calculation/caching) and not the
collected/compiled files.

This change introduces a new view, meant for use with Django's static
serving view, that will collect the referenced file before serving it,
guaranteeing that media like images and fonts are present.

To ensure that this view will return content quickly (especially
considering it will serve up any files referenced by the template tags),
an optimization was made to Collector to allow the caller to collect
only the given list of files. The view makes use of this to handle the
collection process fast.

Adds documentation regarding ES6 config

Included a comment regarding the required file extension of ES6, as this was not immediately obvious to me.

Fixes #550

Add error output for compiler errors within the browser.

Debugging CSS/JavaScript compilation errors can be difficult when viewed
within the context of a Django error page, and if there's a wider
problem with other CSS/JavaScript packages, they won't show up until the
first compilation error is fixed. This is worse if running in a mode
where Pipeline is running but Django error pages aren't being shown.

This change introduces an option, PIPELINE.SHOW_ERRORS_INLINE (now
enabled by default) that outputs any compilation errors at the top of
the page, visually distinguished from the rest of the page, and
containing information on the failing package, command line, and output.
This makes it much easier to debug what went wrong.

The errors are outputted into a hidden div, and then once the page has
fully loaded, they're placed at the top. This allows Pipeline usage
anywhere on the page to promote errors to the top, in the order in which
they're loaded. These also have a default style, but that can be
overridden (and in fact the whole error template overridden) by the
consuming application.

Add support for older Djangos

Support for 1.7 is pretty efortless after #536.
Support for 1.6 is more tricky and involves adding a missing class
(`modify_settings`).

rST wants underlines defining section names to be the same width as the text
above it. This trivial change cleans up those warnings when building the docs.

Add unit tests for the bundled compiler and compressor classes

If this environment variable is not set, multiprocessing throws a
NotImplementedError

Some nodejs executables set stdout and/or stderr to non-blocking, which
can trigger an IOError when the collectstatic command prints more than
1024 bytes at a time to stdout or stderr

shlex.split(), without posix=False, strips "\" characters, which is
obviously problematic on windows.

Fix paths given to compiler.is_outdated.

Allow compilers to override output_path.

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.

The check to see whether or not a source file is outdated was being passed the
`input_path` and `output_path` variables, which are not the actual paths to
files on disk. In particular, `input_path` is the path which will be searched
for using the staticfiles finders, and `output_path` is the relative path
within the staticfiles root. If the staticfiles root was not the same as the
root directory of the project, this would result in the check always reporting
that the file was outdated. In addition, if a source file required a finder to
locate, the check would fail.

Changing this to use `infile` and `outfile` instead means that the check
operates on the same file paths that the compiler will. This therefore checks
the files that were copied by the collector against the files which are
outputted by the compiler, which is a much more correct idea of whether
something is out of date.

This was tested in conjunction with a custom LessCompiler that uses a helper to
introspect dependencies. Before this change, that helper was seeing file paths
that did not exist (since STATIC_ROOT is a few subdirectories deep in our
codebase). Afterwards, it is able to successfully introspect all the source
files to build the dependency tree.

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 current logic for compilers to manipulate output paths is pretty simple,
using `os.path.splitext` and the compiler's `output_extension`. This precludes
doing fancier things by just implementing one's own compiler class.

This change moves the `output_file` method into the CompilerBase class, so that
subclasses can override its behavior to suit their own needs.

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