System::typeinfoName update for GCC 6.2, master branch (2017.08.23.)

This comes from the following ATLAS bug:

https://its.cern.ch/jira/browse/ATLASRECTS-4137

We found, while debugging an issue in one of our own classes, that System::typeinfoName can return unintelligible names for some types. You can reproduce it with the following test for instance:

// System include(s):
#include <iostream>
#include <typeinfo>
#include <vector>
#include <string>
#include <map>

// Gaudi include(s):
#include "GaudiKernel/System.h"

#define PRINT_TYPE( TYPENAME )                                          \
   std::cout << std::endl << #TYPENAME << ": " << std::endl             \
             << System::typeinfoName( typeid( TYPENAME ) ) << std::endl
#define PRINT_TYPE2( TYPE1, TYPE2 )                                     \
   std::cout << std::endl << #TYPE1 << "," << #TYPE2 << ": " << std::endl \
             << System::typeinfoName( typeid( TYPE1,TYPE2 ) )           \
             << std::endl

int main() {

   PRINT_TYPE( std::vector<int> );
   PRINT_TYPE( std::vector<std::string> );
   PRINT_TYPE2( std::map<int,std::string> );
   PRINT_TYPE2( std::map<std::string,int> );

   return 0;
}

With the current code this gives the following with GCC 6.2:

std::vector<int>: 
std::vector<int,std::allocator<int> >

std::vector<std::string>: 
std::vector<std::string,std::allocator<std::string> >

std::map<int,std::string>: 
std::map<int,std::string,std::less<int>,std::allocator<std::pair<int const,std::string> > >

std::map<std::string,int>: 
std::map<std::string,int,std::less<std::string>,std::allocator<std::pair<std::stringconst,int> > >

Notice the std::stringconst part of the last name.

This MR is meant to fix this in a way that doesn't undo the original intention of the code. (Not to produce std::string > names.)

But while we're talking about all of this, I did wonder if we possibly ever want to move some of the ATLAS type name massaging into GaudiKernel itself. As we do find it immensely useful to give the std::type_info of a type to our SG::normalizedTypeinfoName function, and get back a name that TClass::GetClass can actually swallow. But that's for another MR I guess. 😉

P.S. @ssnyder, you probably want to be in the loop on this one.

Fixes GAUDI-1314