Revert "Remove useless code."

This reverts commit 02c6e63ac8dbb8acde3bc19abd36fff0db65fd11. Apparently
types derived from containers can have a container base class without
the container class having a metaclass.

This fixes the sample_strlist unit test crashing. (There may be another
bug here, in Shiboken's don't-write-generated-source-if-not-changed
logic, as the failure doesn't seem to reliably appear/disappear after an
incremental build.)

Change-Id: I5f60bfb784dca02d9766a32e7b7b8a8a529df5af
Reviewed-by: John Ehresman <jpe@wingware.com>
Fix finding container base classes

Move logic to find template classes to its own helper method, and newly
use the helper in AbstractMetaBuilder::getBaseClasses. This fixes the
latter not finding template base classes, which fixes class topological
sorting in some cases.

Unfortunately I have not figured out a reliable unit test for this,
although printing a debug warning when finding the parent fails (or when
a template lookup succeeds) is able to verify that this change is doing
something useful.

Change-Id: I2a5e0df4035393288b6f69ebc41dc0e64866a182
Reviewed-by: John Cummings <jcummings2@users.sf.net>
Don't warn when inheriting from container

Change AbstractMetaBuilder::setupInheritance to not warn about classes
that inherit from known container types, even if the container type does
not have a corresponding wrapper class (which in many or most cases it
won't). Remove now-unneeded suppression for the same in 'sample'.

Change-Id: I0a45636791eba36cf070ea082eb6ead6cb5947ef
Reviewed-by: John Cummings <jcummings2@users.sf.net>
Fix 'special' include handling

Fix handling of includes like '#include BOOST_USER_CONFIG'. This was
failing due to an obvious logic error in how the preprocessor tests if
the expanded symbol looks like an include file location.

Change-Id: Ia085e5c081078d328d6fc84ff2a99681913a30b9
Reviewed-by: John Cummings <jcummings2@users.sf.net>
Fix buffer overrun processing macro definitions

Fix potential buffer overrun (__first iterator becomes > __last and
starts processing garbage) when parsing macro definitions that would
occur if a macro definition ends in a comment. This would cause the
macro definition to contain incorrect content or even outright garbage
(i.e. random memory) if the trailing comment is at the end of the file,
as in boost/type_traits/detail/type_trait_def.hpp. In this worst case,
the macro expansion could contain a NUL byte which would cause parsing
to prematurely halt at the point of expansion.

Change-Id: I94ded39d9a20dc9510d827bc18adb2dc1bad17f0