Run gcc supported flags test without our stricter warning flags

- Fixes fallout from commit f9c69f803f74bd458269c7a06def494ea63387e6:
  running these tests with -Wstrict-prototypes causes all these tests
  to fail as AC_LANG_PROGRAM() uses an incomplete prototype for
  main() :(
Revert "Always return NULL from fdFree()"

- This reverts commit 4c1f7e335de1724661ce63c53186d161ab71a63f:
  various things inside and outside of rpm actually do still depend
  on the old behavior, and leak file descriptors otherwise.
  As an easy backportable band-aid, revert back to the previous
  behavior, to which various callers are tuned to fix the regression
  introduced in rpm 4.10.0. The real fix would be something more like
  "eliminate fdFree() and make Fclose() honor refcounts".
Blargh, more fdFree() braindamage

- Commit 429b933b42d1821f6f0a2a41ae13c504ea6d0657 fixes the fd-leak
  regression in rpm 4.10, but we already have code which relies
  on the new behavior and segfaults with the former one. Adjust
  rpmcpioClose() to the old behavior to get master tree back to
  working shape. TODO: fix this properly some rainy day (oh and see
  http://geekandpoke.typepad.com/geekandpoke/2012/08/likelihood.html)
Only create the first instance of a file shared between packages

- When packages share an identical file, we only need to create the
  first one we encounter and skip it for the rest (reverse already
  happens, and must happen, on erase). This has the benefit of
  getting the timestamp to match the first file, which often is
  also the last one to get removed. Also when lots of shared files
  are involved (such as in multilib installations), this can give
  several percents worth of speed gain as we dont unnecessarily rewrite
  the same contents over and over.
Add a test-case for the shared file timestamp behavior

- Prior to commit f7f5f88f9f3d6587e747b034ccb64a3f00ff4e1e, this
  would've failed: removing the last package to be installed would
  cause timestamp failure on all others. The order is arbitrary in
  this testcase but it matters in real-world situations such as
  secondary arch packages.
Tighten the existing %config tests a bit

- Test for actual file content
- Also clean up any .rpm[new|save|orig] files from the testroot
Add a test-case for another %config file special case

- When an existing config file content changes between package versions
  but the file has already been changed to match the content of the
  new version, we still create a backup file that's identical
  to the one that ends up being installed. This is a bug of sorts,
  but documenting the existing behavior before changing it.
Add further "parametrization" to our config file test spec

- Currently unused but to allow for testing further cases with the
  same base spec...
Adjust the config test descriptions a bit to make room...
Add similar set of %config(noreplace) tests

- The first tests are kinda redundant but extra tests never hurt anybody...
Yet more %config test-cases - shared configs have quirks of their own
Test that the %config backup contents are what we expect

- Note we're only checking the contents where backups *should* be
  created, not much point checking buggy behavior.
Dont create %config backups on skipped files

- This cosmetical only, but there's no point creating the same backup
  twice. Depends on commit f7f5f88f9f3d6587e747b034ccb64a3f00ff4e1e.
Cosmetics: remove unnecessary line-wrap
Dont create redundant %config backups when on-disk content is same as new

- When on-disk %config file contents match the contents of the new
  package (such as config in old package was buggy, fixed in new
  and admin worked around in the meantime) there's no point creating
  a backup that's identical to what you already have. Note that
  we create the new config anyway instead of skipping as timestamp
  might have changed.
- Adjust test-cases to the new saner behavior.
And yet more %config test-cases

- Test behavior when installing over a pre-existing file
- Test behavior on erasure
- Two of the erasure-tests are currently failing due to regression
  introduced in commit 1845c1d711b88723e596c88e8a7730a360029089
Fix %config backup on erasure regression

- After commit 1845c1d711b88723e596c88e8a7730a360029089 erasure
  no longer calls fsmCommit(), missing the backup step entirely.
  Simply split the backup code to a function of its own and call
  as needed. The details look somewhat fishy but what in fsm doesn't...
Further parametrize the config test spec file to allow more cases
Prepare config test-suite to cleaning up directories
Add similar set of %config tests on symlinks

- Several cases are (expectedly) broken here: sometimes backup not
  taken when wanted, sometimes redundant backups taken