Fix type alias creation for instantiations

Modify Binder to correctly qualify type aliases for template
instantiations. This seems to mainly be a problem for type-template
instantiations, but may affect regular instantiations as well. Also
convert the set of qualified types to a QSet (which should be slightly
less expensive than an unused QString value on a QHash). Modify the
tests to exercise the newly-working resolution.

This is in some ways closely related to the previous two commits, and
the test updates are at least partly relevant to those also.

Change-Id: I45ae5ea9573d0c9ba26dd60c3b70056d13e9868c
Fix resolution of instantiation arguments

Modify translateType to also try a canonicalized form of the type name.
This is necessary to resolve function arguments to type-template
instantiations, as the canonical instantiation name has spaces inside
the <>'s, but the function argument has these stripped due to minimal
signature normalization. (Return types are not normalized and so do not
have this problem.)

Change-Id: Ide191042c709f995a04ff7b77855c0e6f80a7d9c
Fix instantiation naming

Fix ::name of AbstractMeta{Type,Class} for type-template instantiations.
These were giving odd results because namespace splitting could split on
a template argument and throw out the actual type name and resulting in
names like 'Object >'. This doesn't seem to obviously affect code
generation (probably it works because the names are still unique for the
cases we've tested so far, but would have collisions in case of more
than one instantiation with the same template argument(s)), but helps
with debugging when inspecting the name()s.

Change-Id: I7de115b31496bf605b9f660d106ba1d6082bfe7f
Omit redirections for protected members

Don't generate redirections to internal class's protected members. This
isn't working right, because it requires a static cast of the inner
class to its wrapper to bypass the access protection, but right now the
generated code is doing the cast on the outer class instead (which is
otherwise the right thing to do). Since 1) it's questionable if
protected methods should be exposed anyway, and 2) likely significant
work to get it working, just disable it for now.

Change-Id: Ia7e3aee3ffd4f670fc74735cec3248dcf8f0d2ef
Always sanitize name of wrapper classes

It isn't obvious why only "inner classes" would need their names
sanitized; at least within our tests, no classes that trip this flag
have names that need to be sanitized. However, names of type template
instantiations must always be sanitized, and there is no ready check for
these at the moment, so just sanitize everything. (It may have just been
for performance reasons that we weren't doing this anyway, but this
shouldn't be in the critical path for that we need to be overly worried
about performance here.)

Change-Id: Ic13089efde9793fc5da8acd049e9d54363f5efa7
Use qualified name for wrapper class name

When generating wrapper classes, use the mangled qualified name instead
of just the base name. This is required to avoid symbol collisions in
the case of wrapping two classes with the same name in different
namespaces.

This doesn't "really" belong on this branch, as it applies to Shiboken
in general, however it effectively depends on the mangling that was
added here, and especially the previous commit, where we changed to
always mangle the wrapper name.

Change-Id: I276a97b4eac4385307a94159437ee4757d88a196
Support type-template function modifications

Modify typesystem parser to (partly) set the correct context for
function additions/modifications to type-template. Modify
AbstractMetaBuilder::createInstantiationMetaClass to add functions from
the type template to the instantiation.

This is only partly complete; template argument types are not yet
supported as types in the function.

Change-Id: Ie6369d2facf3bcd642e9a2a51cbb107046e9094d
Remove unneeded code

Don't bother adding redirection functions to the instantiation type
entry; they are only needed for adding the functions to the abstract
meta objects, which we are doing anyway, and are not needed by the
generate phase, so adding them to the type entry also is superfluous.

Change-Id: I81adc0a3e4d460e98c4a9849da6bbafe65f1ad61
Fix type resolution for type-template functions

Modify type resolution of function modifications to accept a mapping of
template arguments, in order to support e.g. '%INTYPE_0' as return
and/or argument types to functions. This is relevant to function
modifications declared on type templates.

An example of such is added to the sample binding, however there is no
test yet, as functions added to instantiations via type templates are
not being added correctly at the moment. (This will be fixed in the next
commit.)

Change-Id: I8875354547aae2d56d66b5697f1672287717c7b0
Fix type template function additions

Fix the code to add functions from type templates to instantiations to
also copy the code modifications. This fixes the functions being
generated with 'empty' bodies as explained in the previous commit.
Update the unit test to call these, now that they are useful.

Change-Id: I29527973e87cfe7aaf8b5769eb0aa7e7c36ba61f
Fix late resolution of instantiation arguments

Modify ShibokenGenerator::buildAbstractMetaTypeFromString to
canonicalize type names before trying to look up instantiations. Move
canonicalization function to AbstractMetaClass, and use when returning
the name of template instantiation classes.

This should ensure that everyone is looking at the same form of the type
name. This fixes a crash or assertion (depending on whether the type
appears by itself, or as a template type in a container-type) due to
failure to look up the type when it is used in code snippets.

Change-Id: Ic090138a9db9a3acbbd93a9015e07a9504080fd4
Reject container types with unknown arguments

Modify ShibokenGenerator::buildAbstractMetaTypeFromString to explicitly
reject container types if resolution of a template argument type fails.
This prevents us crashing later due to the type having an instantiation
type that is null. (We still exit abnormally, but at least now there is
a useful error message as to why.)

Change-Id: Ief704a7f9d1f50867fc904a5c397435136af9017
Fix redirections of base class methods

Move parsing of instantiation types to after base classes have been
otherwise resolved. Remove resolves argument types from TypeEntry
(nothing outside of AbstractMetaBuilder::traverseInstantiation was using
them, and they're first determined in traverseInstantiation and so don't
need to be stored). Move setting up redirections to its own helper
method so that it can be called recursively to also set up redirections
for the base class and other interface classes (and do so).

The sample binding is accordingly updated to test generation of
redirections of base class members.

Change-Id: Ifb89e0e1c14b7788d1839ec4cf30476012cf832b
Fix creation of duplicate redirections

Change processing of redirections to bind redirections starting with the
most derived class, rather than the other way around, and to ignore
method signatures that have already been bound. This prevents us adding
the same signature more than once, which confuses the overload
resolution and produces generated code with build errors.

Note that this isn't quite right as it doesn't account for the usual
shadowing rules. While this in and of itself would not be hard to
implement, it would possibly cause more harm than good given that we
don't appear to parse 'using' declarations, and so would tend to drop
more methods than we should in real life code.

Change-Id: Ic19776f283153d30b2f1bd56d7969fd535750b26