Move file related defines and typedefs to a new public rpmfiles.h header

- Preparation for making the indexed rpmfiles API public, API users
  are not affected as rpmfiles.h is included from rpmfi.h now. rpmfi.h
  is for the iterator part only.
Make the relevant rpmfiles accessor functions public

- All the public rpmfiFoo() accessors have an indexed rpmfilesFoo()
  counterpart, make the rpmfiles-versions public too.
- The noteworty exceptions are rpmfiDecideFate() and rpmfiConfigConflict()
  which shouldn't have been public in the first place, and are to be
  removed from the API in the next API break. So we're not adding
  new rpmfiles-counterparts for functions that are to be removed
  from the (public) API. Actually document the issue by deprecating
  both rpmfi-functions.
- The iterator types need to be in rpmfiles.h as the iterator
  constructor is there (otherwise there'd be a cyclic include
  between rpmfiles.h and rpmfi.h, which wont do...)
Document rpmfiles API, tweak rpmfi docs a bit to differentiate

- rpmfiles API is mostly a copy-paste of rpmfi with index argument
  added
- clarify rpmfi.h docs to speak about "file info set iterator",
  rpmfiles.h is the "file info set" thing now
Clarify + document rpmfiles directory vs file index

- Rename the file index argument for rpmfnDI(), rpmfilesDI() and
  rpmfilesODI() to ix for consistency with other file index arguments
- Document rpmfilesDI() and rpmfilesODI() and its usage with rpmfilesDN()
  and rpmfilesODN()
Add basic python bindings for rpm string pool

- Python users are unlikely to have much use for this thing as such,
  python has plenty enough native datatypes to not bother with rpm
  specialties. The primary reason for adding it is to allow utilizing
  a shared string pool for various rpm objects from python side as
  well. That'd only require being able to pass the pointer around
  for which we wouldn't need a full-blown object, but otoh creating
  test-suitet cases in python is nicer than in C so having at least
  the base methods available wont hurt...
Use the pool-aware constructors for rpmfi and all rpmds types

- Doesn't actually change anything yet as pool is always NULL
Allow a shared pool with python rpmds and rpmfi objects

- Add an optional pool argument to python rpmds and rpmfi constructors
  to allow using a shared string pool from python too
Add a couple of basic tests for python stringpool
Python 3 compatibility wrt python fi.FindFN()

- Strings from rpm are byte arrays from python 3 perspective
Remove bogus __find_requires|provides macro definitions (RhBug:1043149)

- The paths defined in macros.perl have never even existed in rpm,
  would've always been suspect and nowadays mostly just plain useless
  as they'd only be used by the deprecated external dependency
  generator.
New rpmfile[s] python bindings

- rpmfiles is represented as a sequence of individual files, thus
  its iterable as-is
- Individual files are handled internally as index on rpmfiles handle,
  all data made available as read-only properties
- We can now consider the old, bizarre rpm.fi bindings as deprecated
Export rpmteFiles(), deprecate rpmteFI()

- rpmteFiles() is the saner interface of the two, rpmteFI() is only
  kept around for backward API compatibility, for now
Add python binding for rpmteFiles(), update docs
Construct mode as understood by librpmio in rpmfd constructor already

- No functional change here, but we'll need this for the next step
Honor mode and flags also when reopening an fd in python rpm.fd
Support reopening an rpm.fd descriptor as well
Add couple of missing RPMFILE_* symbols to python bindings
Remember open-mode and flags in python rpm.fd's as properties
Add .open() class method to rpm.fd

- This is simply equivalent of calling rpm.fd constructor, but
  might be somewhat more natural way of opening files
Dup the file descriptor when reopening an rpm.fd in python

- Avoids a segfault on closing in some circumstances