Add + use a flag for identifying automatic macros

- In practise doesn't change anything visible as the "macro not used"
  message is disabled, but tracking a flag bit is saner than
  strlen() + strchr() + bunch of other stuff which isn't even correct:
  prior to this %## would've triggered "unused" errors which is plain
  wrong, and complaining about unused %1 %2 ... isn't really right
  either.
Move macro usage tracking to flags

- We dont really care how many times a macro has been used, just
  whether it has been used or not...
Make macro deletion in freeArgs() optional

- Not used yet, but using this for issuing warnings only
Consider macro used if we've so much as looked it up
And finally, actually enable the unused macro warning.

- Reword the message to something hopefully little more understandable,
  change from error to a warning (only matters for output)
- Check unused macros at end of every scope, but unlike with parametrized
  macros, dont actually delete
- Only whine once per unused macro due to the above to avoid spurious
  output due to above
- This catches the common error in specs where %define is used in a scope
  unintentionally, eg "%{!?foo: %define foo 1}" where the just defined
  macro should actually fall out of scope upon the closing }, but
  only gets erased if any parametrized macro is "called" and causes
  insane behavior such as described in RhBug:552944. So at least we'll
  warn on these situations.
Relax multiple %files sections for a package into a warning

- Because of the missing check, multiple empty %files sections could
  be abused for the effect of multiple -f arguments back when that
  was not supported. The weird corners people find...
- Turn it into a warning and preserve former behavior, except avoid
  leaking memory in this case.
Relax duplicate i18n tag check into a warning as well

- Because the check has been missing, these flaws are all over the
  place. Duplicates are not really worth breaking existing specs, so just
  warn for now, and preserve last one wins-behavior.
Make rpmtsPrunedIterator() internally available
Legalize proper reinstall within transaction

- Account for packages removed in transaction when checking whether
  package is already installed. This permits install + erasure of the
  same package within a single transaction, aka reinstall, with
  changing file policies (excludedocs, installangs etc) properly
  taken into account. Related to RhBug:966715.
- This differs from --replacepkgs which is just a strange hack really
  but one that's difficult to change because of how its presented
  in the API. --replacepkgs behavior does not change here, and a proper
  reinstall is NOT possible when replacepkg problem filter is active.
- Testing this is not possible with rpm cli :(
Refactor to make room for other operations besides install/upgrade

- Add enumeration for install-style operations
- Refactor the guts of rpmtsAddInstallElement() into an internal
  helper operatins around the new enums
- Any functional change by this commit would be a bug...
Add support for proper package reinstallation to in the API

- Add new public rpmtsAddReinstallElement() function for properly
  reinstalling packages within a single transaction, ie one that
  behaves like it was upgrade to the same version, removing files
  on changed policies (excludedocs etc).
- This could've been done by redefining the "upgrade" argument of
  rpmtsAddInstallElement() to an "operation", but as the upgrade
  argument accepted values are not clearly defined this could
  have unwanted side-effects, plus this way its also easier to test
  whether reinstall is supported by rpm.
- Related to RhBug:966715
Add python bindings for reinstall

- Again, this could've quite easily been done by accepting "r"
  as "how" argument to addInstall(), but this makes testing for
  rpm support much easier. Otherwise not much to see here...
- Related to RhBug:966715 / RhBug:1071854 ... etc
Add --reinstall command to rpm cli

- Handle reinstall as a new sub-mode of install, leaving all the
  --replacepkgs etc insanity alone, at least for now. For rpm cli we
  could probably remap --replacepkgs into proper reinstall, but handling
  this in the API is much harder as problem filter flags, such as
  RPMPROB_FILTER_REPLACEPKG, are not known at the time packages
  are added to transaction, and also we can't very well go and
  add new elements to the transaction from inside rpmtsRun()
- Fixes the use-case of RhBug:966715 but not the exact cli invocation
  in that bug... that needs something different
Dumb dumb typo in commit bf856744f2820a1625ef9428284b5788d18103f3
Add a basic test-case for reinstall
Remove no longer needed rpmfi_internal.h include
Redo hard link handling when installing packages

As we now know the hardlinks in advance we can just create the files during the first pass.
Kill fsm->action
Kill fsm->dirName and fsm->baseName