rpmdb changes

Review transactional "RPM ACID" vs traditional concurrent models.

There are 2 approaches to #911292 solution:
    1) add a new Nevra table used solely for Mandriva Distepoch/Disttag
    2) change the Nvra table to contain different content on Mandriva systems
The criterion for choosing what is done will be based on least intrusiveness
to the @rpm5.org code base.

This change is in effect a "schema change", and a new table can be deployed most
easily. There are deeper issues however, since Nvra is by far _THE_ most used
table lookup for RPM based package management, and its likely easier to
hack different content into the Nvra table for re-use by all applications than
it will be to wait for the predictable whining from application developers claiming
     RPM changed and broke my application!
even though the change is publicized and announced and @rpm5.org is trying
to removed per-vendor "Have it your own way" #ifdef RPM_VENDOR_MANDRIVA
compiled in behavioral changes: Mandriva is too peculiar for those changes
to be maintainable in @rpm5.org cvs imho.

From feedback: "Which is more important: performance or reliability?"
My short answer is "reliability".