Add coverage badge, update package

Also, intentionally exclude TravisCI files, to match excluding test
files, and make check-manifest happy.

Test support for Django 1.11, dev

pypy is 2.5.0, which is compatible with Python 2.7.13.
pypy3 is 2.4.0, which is compatible with Python 3.2, and won't work with
pip.

- Use new urlpattern syntax
- Switch .travis.yml to matrix form, to specify specific Python versions
- Remove invalid docsinstall and double install from .travis.yml
- Add Django 1.11 and master (allowed failure) targets, and Python 3.6
- Add doc target to .travis.yml

added compiler_options field

Fix css url detector regex.

Fixes using forward-slashed paths on Windows

Replace os.rename with shutil.move

Fix to view compile error if happens.

If compile error happens, we cannot see it. Instead, ‘context must be a dict rather than Context’.
Django 1.11. Regarding to docs, the same down to 1.7.

Django allows forms and widgets to define the CSS or JavaScript files
needed on the page, automatically including those files in the
administration UI. This works fine for standalone media files, but
weren't an option for Pipeline packages.

This change introduces a branch new `PipelineFormMedia` class that a
form or widget's Media class can inherit from. The Media class can then
define `css_packages` or `js_packages` attributes that work just like
the standard `css`/`js` attributes but reference package names instead
of individual files.

Upon accessing the `css`  or `js` attributes, the files defined in the
packages will be collected/processed just like with the template tags
and the resulting filenames returned for use in the page.

Using this, any page compatible with Django's form media support will
work automatically with any form or widget that wants to use Pipeline
packages, without any modifications to templates or any other
workarounds that were needed before.

This implements issue #154.

See:
- http://stackoverflow.com/a/8107391
- https://docs.python.org/2/library/os.html?highlight=os.rename#os.rename

Fix a regression in determining when to collect static files.

A commit made in 1.6.10 (ae6b3f8e)
changed a storage lookup to use the prefixed_path variable instead of
the path variable when looking up modification times in order to
determine if an existing collected file should be deleted and
re-collected. By using the wrong path variable, the storage lookups
always failed, resulting in every single file being re-collected every
single time.

This reduces performance considerably, particularly with large codebases.
Since every file ends up copied, they appear as new and are recompiled.
This can result in very long page reloads on a development server,
especially if working on an older machine, in a VM, on a shared
filesystem, or on the Linux subsystem for Windows.

This is a simple change that fixes the lookup to use the correct
variable. Unit tests were added to ensure this continues to work as
expected and does not regress.

Fixing compatibility bug to support Django 1.10 new style middleware

Fix formatting and structure

Start Django 1.10 compatibility