make source record parsing compatible

Continueing in the "fix it or unexport it" is now parsing of source
records in the focus (which has more sideeffects than you would expect).

We need this fix to be able to ship a security-improvement for "apt-get
source", but that needs slight source changes to be effective.
compat for indexRecords to parse all hashes

The biggest feature backported here is the storage of all available
hashes we can find in the Release files. We make use of this in the
acquire system to improve security, so having it is quiet nifty.
The trick is a static d-pointer and an additional lookup method to get
all hashes for the requested file.
abi-compat for pkgRecords

We did most of it with pkgSrcRecords already, but the non-source part
has a similar problem and therefore also a similar solution.
restore ABI compatibility for Hashes

We do again the static-d trick to have a way to store the filesize.
Special care is to be taken as the methods were previously mostly
inline, especially our Add() method responsible for the filesize, so to
support old clients calling the old inlined method the filesize will
only be part of the generated HashStringList if its not zero (on the
upside, empty files are pretty uncommon for us). Also, as this class
used default con- and destructor before we can't be sure that they are
called, so this could also contribute to not using filesize as a check.
The solution to all this is a recompile (and the most prominent user is
the library itself, so we get this for free).
drop SourcePkgName/VerStr from pkgCache::Version

We can't add two new fields to such a lowlevel struct without getting us
into major pain, so we revert this for now as it isn't used in any
critical path for now. We can get it back on the next abi break – as
with the other changes to the structs we did for cleanup: Mainly size
changes to be better prepared for the future. In other words: This
commit is a defeat on all fronts expect that we have retained the
possibility to have a dynamic Pkg/GrpHashTable with the downside of
having some dormant bytes in the cache.
partly revert CacheSet rework for abi-compat

The redesign requires a bunch of virtuals to be effective, so that can't
happen, but what we can do is move everything to the place it belongs as
you couldn't override the behavior before anyway, so this isn't a
regression and we are one step closer at a cleaner interface.
acquire system rework rework for abi-compat

The acquire system got a major overhaul to eliminate some future
security problems and better deal with interrupted updates by a
invalid file. As most of these changes happen in places nobody is
touching, I am again liberal with the unexport flag. We have some more
globally useful classes for file acquiring through, so these have to be
handled with care.
flip back the abi number

After all this work, we are finally done!

As a summary: This is neither ABI nor API compatible in the strict
sense, but in practice it seems fine.