When using pybind11 to bind enums on MSVC and warnings (/W4) enabled,
the following warning pollutes builds. This fix renames one of the
occurrences.

pybind11\include\pybind11\pybind11.h(1398): warning C4459: declaration of 'self' hides global declaration
pybind11\include\pybind11\operators.h(41): note: see declaration of 'pybind11::detail::self'

* Add basic support for tag-based static polymorphism

Sometimes it is possible to look at a C++ object and know what its dynamic type is,
even if it doesn't use C++ polymorphism, because instances of the object and its
subclasses conform to some other mechanism for being self-describing; for example,
perhaps there's an enumerated "tag" or "kind" member in the base class that's always
set to an indication of the correct type. This might be done for performance reasons,
or to permit most-derived types to be trivially copyable. One of the most widely-known
examples is in LLVM: https://llvm.org/docs/HowToSetUpLLVMStyleRTTI.html

This PR permits pybind11 to be informed of such conventions via a new specializable
detail::polymorphic_type_hook<> template, which generalizes the previous logic for
determining the runtime type of an object based on C++ RTTI. Implementors provide
a way to map from a base class object to a const std::type_info* for the dynamic
type; pybind11 then uses this to ensure that casting a Base* to Python creates a
Python object that knows it's wrapping the appropriate sort of Derived.

There are a number of restrictions with this tag-based static polymorphism support
compared to pybind11's existing support for built-in C++ polymorphism:

- there is no support for this-pointer adjustment, so only single inheritance is permitted
- there is no way to make C++ code call new Python-provided subclasses
- when binding C++ classes that redefine a method in a subclass, the .def() must be
  repeated in the binding for Python to know about the update

But these are not much of an issue in practice in many cases, the impact on the
complexity of pybind11's innards is minimal and localized, and the support for
automatic downcasting improves usability a great deal.

The property returns the enum_ value as a string.
For example:

>>> import module
>>> module.enum.VALUE
enum.VALUE
>>> str(module.enum.VALUE)
'enum.VALUE'
>>> module.enum.VALUE.name
'VALUE'

This is actually the equivalent of Boost.Python "name" property.

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

I think that there's the word "for" missing for that sentence to be correct.
Please double-check that the sentence means what it's supposed to mean. :-)

This reimplements the version check to avoid sscanf (which has
reportedly started throwing warnings under MSVC, even when used
perfectly safely -- #1314).  It also extracts the mostly duplicated
parts of PYBIND11_MODULE/PYBIND11_PLUGIN into separate macros.

- PYBIND11_MAKE_OPAQUE now takes ... rather than a single argument and
  expands it with __VA_ARGS__; this lets templated, comma-containing
  types get through correctly.
- Adds a new macro PYBIND11_TYPE() that lets you pass the type into a
  macro as a single argument, such as:

      PYBIND11_OVERLOAD(PYBIND11_TYPE(R<1,2>), PYBIND11_TYPE(C<3,4>), func)

  Unfortunately this only works for one macro call: to forward the
  argument on to the next macro call (without the processor breaking it
  up again) requires also adding the PYBIND11_TYPE(...) to type macro
  arguments in the PYBIND11_OVERLOAD_... macro chain.
- updated the documentation with these two changes, and use them at a couple
  places in the test suite to test that they work.

Apparently with homebrew the correct package for python3 is now just
`python`; python 2 was relegated to 'python@2', and `python3` is an
alias for `python` (which needs to be upgraded rather than installed).

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.

This function already has a `using namespace detail`, so all the
`detail::` qualifications are not needed.

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).

* Fix segfault when reloading interpreter with external modules

When embedding the interpreter and loading external modules in that
embedded interpreter, the external module correctly shares its
internals_ptr with the one in the embedded interpreter.  When the
interpreter is shut down, however, only the `internals_ptr` local to
the embedded code is actually reset to nullptr: the external module
remains set.

The result is that loading an external pybind11 module, letting the
interpreter go through a finalize/initialize, then attempting to use
something in the external module fails because this external module is
still trying to use the old (destroyed) internals.  This causes
undefined behaviour (typically a segfault).

This commit fixes it by adding a level of indirection in the internals
path, converting the local internals variable to `internals **` instead
of `internals *`.  With this change, we can detect a stale internals
pointer and reload the internals pointer (either from a capsule or by
creating a new internals instance).

(No issue number: this was reported on gitter by @henryiii and @aoloe).

Fix return from `std::map` bindings to `__delitem__`: we should be returning `void`, not an iterator.

Also adds a test for map item deletion.

Found via `codespell`

The anonymous struct nested in a union triggers a -Wnested-anon-type
warning ("anonymous types declared in an anonymous union are an
extension") under clang (#1204).  This names the struct and defines it
out of the definition of `instance` to get around to warning (and makes
the code slightly simpler).

- UPDATEIFCOPY is deprecated, replaced with similar (but not identical)
  WRITEBACKIFCOPY; trying to access the flag causes a deprecation
  warning under numpy 1.14, so just check the new flag there.
- Numpy `repr` formatting of floats changed in 1.14.0 to `[1., 2., 3.]`
  instead of the pre-1.14 `[ 1.,  2.,  3.]`.  Updated the tests to
  check for equality with the `repr(...)` value rather than the
  hard-coded (and now version-dependent) string representation.

PEP8 indicates (correctly, IMO) that when an annotation is present, the
signature should include spaces around the equal sign, i.e.

    def f(x: int = 1): ...

instead of

    def f(x: int=1): ...

(in the latter case the equal appears to bind to the type, not to the
argument).

pybind11 signatures always includes a type annotation so we can always
add the spaces.

* Make register_dtype() accept any field containers

* Add a test for programmatic dtype registration

When using the mixed position + vararg path, pybind over inc_ref's
the vararg positions. Printing the ref_count() of `item` before
and after this change you see:

Before change:

```
refcount of item before assign 3
refcount of item after assign 5
```

After change
```
refcount of item before assign 3
refcount of item after assign 4
```

The `py::args` or `py::kwargs` arguments aren't properly referenced
when added to the function_call arguments list: their reference counts
drop to zero if the first (non-converting) function call fails, which
means they might be cleaned up before the second pass call runs.

This commit adds a couple of extra `object`s to the `function_call`
where we can stash a reference to them when needed to tie their
lifetime to the function_call object's lifetime.

(Credit to YannickJadoul for catching and proposing a fix in #1223).

In the latest MSVC in C++17 mode including Eigen causes warnings:

    warning C4996: 'std::unary_negate<_Fn>': warning STL4008: std::not1(),
    std::not2(), std::unary_negate, and std::binary_negate are deprecated in
    C++17. They are superseded by std::not_fn(). You can define
    _SILENCE_CXX17_NEGATORS_DEPRECATION_WARNING or
    _SILENCE_ALL_CXX17_DEPRECATION_WARNINGS to acknowledge that you have
    received this warning.

This disables 4996 for the Eigen includes.

Catch generates a similar warning for std::uncaught_exception, so
disable the warning there, too.

In both cases this is temporary; we can (and should) remove the warnings
disabling once new upstream versions of Eigen and Catch are available
that address the warning. (The Catch one, in particular, looks to be
fixed in upstream master, so will probably be fixed in the next (2.0.2)
release).