Switch RPM build compiler from cc to c++

There's an increasing need to switch the compiler used
building RPM to C++.

The reasons are as follows:

0) making all includes C++ ready
  RPM in C has a risk factor when include files are used in C++
   which is often pickier wrto casts and typedef's. There has
   never been any attempt to support C++ fully: changes have
   always been fixed on an as needed/reported basis. But the
   bug report always comes in after the release, and so cannot
   really be solved reactively. proactively "dog fooding" by
   using C++ as compiler will ensure that include files are C++ ready
   when released.

1) exception handling
  RPM (like many C programs) returns errors synchronously. As the
  needs for better error handling increase, there are only a couple
  of ways to satisfy the expectations:
     a) break the API/ABI to unravel increasingly complex calling chains
     b) start using C exceptions (aka setjmp(3) and longjmp(3))
   C++ (unlike C) already has well-defined exceptions built in.

2) objects => classes
  RPM development over the last few years has progressed with a strong
  sense of a reference counted "object" with shared ctors/dtors and memory
  allocation pools. There are approx 30-40 "objects" in RPM now, essentially
  (in C++ terms) all subclassed from a common base class which handles
  the reference counting (protected by pthread mutexes and so "thread-safe").

  There are benefits (imho) to continue mapping the C objects => C++ classes
   so that C++ permits sub-classing (when needed) as "supported" development

What I am _NOT suggesting is that RPM should be rewritten in C++ with all the
Baroque'n Newer! Better! Bestest! feature bloat. That is out of scope for this
blueprint.

The model SHOULD be similar to what Mozilla did in libjs between 1.8.1 -> 1.8.2. The compiler
changed C -> C++ in a minimally intrusive fashion.