builds against a python debug library were unreliable and
could lead to symbol errors during linking.

Setting the `Py_DEBUG` define is necessary when linking
against a debug build:

https://stackoverflow.com/questions/39161202/how-to-work-around-missing-pymodule-create2-in-amd64-win-python35-d-lib

https://docs.python.org/2/c-api/intro.html#debugging-builds

https://docs.python.org/3.6/c-api/intro.html#debugging-builds

* VS 15.8.0 Preview 4.0 has a bug with alias templates

Catch v2 changed the `run(...)` signature to take a `char *argv[]`,
arguing partly that technically a `char *argv[]` type is the correct
`main()` signature rather than `const char *argv[]`.

Dropping the `const` here doesn't appear to cause any problems with
catch v1 (tested against both the cmake-downloaded 1.9.3 and Debian's
1.12.1 package) so we can follow suit.

* stl.h: propagate return value policies to type-specific casters

Return value policies for containers like those handled in in 'stl.h'
are currently broken.

The problem is that detail::return_value_policy_override<C>::policy()
always returns 'move' when given a non-pointer/reference type, e.g.
'std::vector<...>'.

This is sensible behavior for custom types that are exposed via
'py::class_<>', but it does not make sense for types that are handled by
other type casters (STL containers, Eigen matrices, etc.).

This commit changes the behavior so that
detail::return_value_policy_override only becomes active when the type
caster derives from type_caster_generic.

Furthermore, the override logic is called recursively in STL type
casters to enable key/value-specific behavior.

Switching deprecated Thread Local Storage (TLS) usage in Python 3.7 to Thread Specific Storage (TSS) (#1454)

* Switching deprecated Thread Local Storage (TLS) usage in Python 3.7 to Thread Specific Storage (TSS)

* Changing Python version from 3.6 to 3.7 for Travis CI, to match brew's version of Python 3

* Introducing PYBIND11_ macros to switch between TLS and TSS API

* Silence GCC8's -Wcast-function-type.

See https://bugs.python.org/issue33012 and PRs linked therein.

It is useful not only to remember the python libs and includes but
also the interpreter version in cache.

If users call pybind11 throught `add_subdirectories` they will
otherwise have no access to the selected interpreter version.
The interpreter version is useful for downstream projects, e.g.
to select default `lib/pythonX.Y/site-packages/` install paths.

Add missing python3 distutils on Debian "buster".

If an exception is thrown during module initialization, the
error_already_set destructor will try to call `get_internals()` *after*
setting Python's error indicator, resulting in a `SystemError: ...
returned with an error set`.

Fix that by temporarily stashing away the error indicator in the
destructor.

Found via `codespell`

Fixes #1401

Fix a segfault when creating a 0-dimension, c-strides array.

As reported in #1349, clang before 3.5 can segfault on a function-local
variable referenced inside a lambda.  This moves the function-local
static into a separate function that the lambda can invoke to avoid the
issue.

Fixes #1349

This fixes the test code on big-endian architectures: the array support
(PR #832) had hard-coded the little-endian '<' but we need to use '>' on
big-endian architectures.

Current MSVC generates totally bizarre errors:

    error C2884: 'pybind11::detail::_': introduced by using-declaration
    conflicts with local function 'pybind11::detail::_'

which makes no sense (since the supposed "conflict" is the function
itself).  Work around it by `using namespace detail;` instead (which
also lets us drop a bunch of other `detail::` qualifications, so isn't
actually a bad thing).

This updates the `py::init` constructors to only use brace
initialization for aggregate initiailization if there is no constructor
with the given arguments.

This, in particular, fixes the regression in #1247 where the presence of
a `std::initializer_list<T>` constructor started being invoked for
constructor invocations in 2.2 even when there was a specific
constructor of the desired type.

The added test case demonstrates: without this change, it fails to
compile because the `.def(py::init<std::vector<int>>())` constructor
tries to invoke the `T(std::initializer_list<std::vector<int>>)`
constructor rather than the `T(std::vector<int>)` constructor.

By only using `new T{...}`-style construction when a `T(...)`
constructor doesn't exist, we should bypass this by while still allowing
`py::init<...>` to be used for aggregate type initialization (since such
types, by definition, don't have a user-declared constructor).