Header reorganization

#679 initially added a detail/ directory to the header includes. It was withdrawn to be discussed later in a separate issue/PR; this is meant to be the start of discussion. Also read the following not as a done deal, but as a request for comments where I'm mostly thinking out loud to start the discussion.

I think we should make the move for most (or even all?) of our detail namespace code. Basically, all the things in class_support.h are an obvious first start to move to detail/class.h; but there are also many other potential additions:

Detail headers

• the various template meta-code in common.h (for things like satisfied_all_of, would fit nicely into a detail/meta.h. It's relatively centralized now (in common.h), but that hasn't always been the case and has led to me, at least, occassionally duplicating meta template functionality that was already implemented (but implemented elsewhere, i.e. immediately before it was used/needed).

• The same sort of moving of detail namespace bits into detail-namespace companions would be a nice cleanup to the non-detail code. E.g. pybind11.h's generic_type and init classes, keep alive implementation, etc. are all already in the detail namespace; moving them into a detail directory header would be appropriate.

Type casters

Along a similar line, we could move type caster implementations into their own namespace, pybind11::cast, and directory, pybind11/cast. For now, for backwards compatibility, cast would be a namespace alias of detail, but the plan would be to eventually drop the alias so that all type casters live as pybind11::cast::type_caster<T>, thus having external type casters put themselves in the detail namespace.

Thus you would include pybind11/cast/stl.h for stl casters, pybdin11/cast/eigen.h for eigen casters, etc. (The current pybind11/stl.h, pybind11/eigen.h would just one-line compatibility headers that just include the new location).

Many of the built-in casters would be usefully moved as well:

• the arithmetic caster in cast/arithmetic.h
• std::string and char* casters to cast/string.h
• std::pair/std::tuple into cast/tuple.h
• pointer casts, null casters, generic casters I think could remain in cast.h.
• the argument loader seems a bit out of place in cast.h—I think it's there mainly for historic reasons, since it was originally part of the std::tuple caster. Perhaps detail/argloader.h?

Start by reviewing class_support.h, common.h, pybind11.h, cast.h, stl.h, and eigen.h to understand the current header and namespace layout. The issue is an open-ended discussion, so the work is not yet defined; done would require an agreed organization and compatibility plan before implementation.