Data Definitions should not include mangled C++ names

[Jeff Johnson]

This bug is split from bug 3883, which may get closed.

Defines, data types and function signatures are emitted into build_env .defs
files, which become the Data Defintions in the LSB specification. In the case
of libraries implemented in C++, many elements are recorded with mangled names,
because the actual ABI is implemented by libraries which contain such symbols.

The LSB data import of C++ libraries is incomplete, and is not used to generate
working headers. Headers are in fact generated, but are not included in the
SDK, instead headers built from the source tarballs of the matching upstream
projects (currently libstdc++, Qt3 and Qt4) are used. In the case of the data
definitions, inclusion is only partial - some purely C++ elements like class
definitions are not produced, but what is put into the .defs files is used
complete and as-is in the specification. In researching for bug 3883, it
became evident that Enum types are handled incorrectly - because mangled names
are used. For example, for example, from:

http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Desktop-generic/LSB-Desktop-generic/libqtcore-ddefs.html

we see:

17.3.61. QtCore/qthread.h

class QThread;
enum _ZN7QThread8PriorityE {
    IdlePriority = 0,
    LowestPriority = 1,
    LowPriority = 2,
    NormalPriority = 3,
    HighPriority = 4,
    HighestPriority = 5,
    TimeCriticalPriority = 6,
    InheritPriority = 7
};

It's pretty clear that if we're going to include this enum it should use the
unmangled name. The Type entry does contain this name:

INSERT INTO `Type` VALUES (15516,
==> '_ZN7QThread8PriorityE','Enum',735,'','No','No','No',
==> 'QThread::Priority',0,0,'libQtCore',0);

In the upstream header we see this as:

class Q_CORE_EXPORT QThread : public QObject
{
public:
...
    enum Priority {
        IdlePriority,

        LowestPriority,
        LowPriority,
        NormalPriority,
        HighPriority,
        HighestPriority,

        TimeCriticalPriority,

        InheritPriority
    };

else we could leave out the enums entirely, not sure which makes more sense.
The values of the enum elements should be fixed as that is part of the ABI, but
since none of the rest of the class contents are listed....