Dropping GCC 4.6 support from master

[mosra]

GCC 4.7 has nearly complete C++11 support with many useful features not present in 4.6. These features are already conditinally used for public API (surrounded with #ifndef CORRADE_GCC46_COMPATIBILITY), but using them also internally would greatly simplify the maintenance.

Offered features

• Delegating constructors -- now they are emulated with various initialize() methods or, in Math namespace, with assignment operators. It is unsafe (nothing prevents us from calling initialize() twice), leads to code duplication, causes double initialization and hurts constexpr optimizations.
• User-defined literals -- using them internally (mainly tests) would help readability. Also we can't use them in examples, thus it looks like they aren't present at all.
• Template aliases -- apart from cleaner internals (e.g. using BasicAnimable3D<T> instead of Animable<3, T>) it would shorten type traits a lot. C++14 introduces aliases for many STL type traits, so if we would inspire with that and write VectorTypeFor<dimensions, T> instead of typename DimensionTraits<dimensions, T>::VectorType everywhere, it would lighten up many dark corners.
• Override and final are already used, but having #define override for GCC 4.6 is too fragile and I don't want this type of workaround in master.
• Non-static data member initializers would help with code deduplication in constructor initializer lists.
• Using std::underlying_type for "downcasts" of strongly-typed enums instead of explicitly mentioning the type every time we need to convert it to GL* type. Also this will simplify usage of Corrade::Containers::EnumSet class.
• Using both const and constexpr for variables (forward compatibility with C++14).
• More complete STL API, e.g. std::unordered_map::emplace().
• Ability to use -std=c++11 instead of -std=c++0x.

Compatibility branch

Support for GCC 4.6 would be moved to compatibility branch to live there with 4.4 and 4.5 compatibility workarounds. These are maintained mainly for Google Chrome Native Client toolchain.

Other compilers

It's awesome that all these features are already supported in Clang 3.1, so we can stay with current Clang requirements. Visual Studio 2013 needs compatibility branch anyway.

Platform support

Goal is to not force users on important platforms to develop from compatibility branch. Doing development on it is less convenient, it gets less frequent updates and is generally not advisable, as the workarounds there might cause subtle issues when compiling the code on master branch.

Windows, OSX

MinGW has 4.7 since a long time, OSX users are using Clang exclusively.

Linux distributions

The only distribution I know of which still has GCC 4.6 is Ubuntu 12.04 LTS. Is there any other distro I forgot? Next LTS will be 14.04 which is still some time ahead, would it be worth it to keep the compatibility until 14.04 is released and at least partially adopted (Q2 2014)?

Android

GCC 4.8 is supported since NDK r9, 4.7 since r8d (which was then dropped in r9c) and 4.6 since r8b (until r8b there was only 4.4). Clang is supported since r8c. Thus the minimal supported version would be r8d (because even with Clang we need at least libstdc++ from GCC 4.7), need to make sure that all older Androids down to 2.3 are supported by r8c.

NaCl

The x86 toolchain still uses 4.4 (and thus needs compatibility branch anyway), the PNaCl uses Clang and ARM toolchain uses 4.7.

iOS

Even that the library doesn't yet support it, we need to check things to not make the later port too inconvenient by requiring compatibility branch. The showstopper would be if the toolchain uses libstdc++ from GCC 4.6, but I think they are on Clang and libc++.

[mosra]

Significant part done in a9a5ead, cbe63c7, 7f38cca, 4a4768a, 5a020ab and 757ca6d.