GitLab

* Add debugging info about so size to build output

This adds a small python script to tools that captures before-and-after
.so sizes between builds and outputs this in the build output via a
string such as:

------ pybind11_tests.cpython-35m-x86_64-linux-gnu.so file size: 924696 (decrease of 73680 bytes = 7.38%)

------ pybind11_tests.cpython-35m-x86_64-linux-gnu.so file size: 998376 (increase of 73680 bytes = 7.97%)

------ pybind11_tests.cpython-35m-x86_64-linux-gnu.so file size: 998376 (no change)

Or, if there was no .so during the build, just the .so size by itself:

------ pybind11_tests.cpython-35m-x86_64-linux-gnu.so file size: 998376

This allows you to, for example, build, checkout a different branch,
rebuild, and easily see exactly the change in the pybind11_tests.so
size.

It also allows looking at the travis and appveyor build logs to get an
idea of .so/.dll sizes across different build systems.

* Minor libsize.py script changes

- Use RAII open
- Remove unused libsize=-1
- Report change as [+-]xyz bytes = [+-]a.bc%

This makes the output considerably easier to use: it now highlights (in
red) matched tabs (instead of just listing the filenames), and adds
line numbers to both the tabs check and the space-less if check outputs.

The check-style exit status wasn't being propagated properly because
the loops were running in a subshell (and so the change the the
`errors` variable wasn't in the active command shell).  This fixes it
by running the greps in subshells and the loops in the main shell.

This also avoids the if(/for(/while( style check on
tests/CMakeLists.txt, since it *does* have if() statements with no space
that are producing error messages, but that is (acceptable) CMake style.

This adds a tool that checks style (currently just for tabs instead of
spaces in files under include/tests/docs) and produces a travis-ci build
failure if any problems are found.

Fixes #365. `sysconfig.get_config_var('SO')` already returns the correct
PYTHON_MODULE_EXTENSION, even for debug builds, so there is no need to
add anything else manually.

When run on windows in a venv, PYTHON_LIBRARY pointet to a non-existant
location in the virtual environment directory.

This has been fixed by testing if the path exists and, if not, trying
an alternative path, relative to the PYTHON_INCLUDE_DIR.

If the alternative path doesn't exit as well, an error will be raised.

Also:
- Update documented result variables
- Remove long-ago-deprecated variable

This prevented `DOC(...)` calls with 5 arguments to resolve correctly.