Some packages, like `krb5-multidev`, include several .so files to link
against in their pkg-config files:
```
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu/mit-krb5
includedir=${prefix}/include/mit-krb5
defccname=FILE:/tmp/krb5cc_%{uid}
defktname=FILE:/etc/krb5.keytab
defcktname=FILE:/etc/krb5/user/%{euid}/client.keytab
Name: mit-krb5
Description: An implementation of Kerberos network authentication
Version: 1.20.1
Cflags: -isystem ${includedir}
Libs: -L${libdir} -lkrb5 -lk5crypto -lcom_err
Libs.private: -lkrb5support
```
So, instead of assuming that we have one cc_library per pkgconfig file,
we just collect all the declarations and create one `cc_import` target
for each.
Some design considerations:
### Does this violate the private-ness of `Libs.private`?
All `cc_imports` we create have private visibility already, so I don't
think it does.
### Why not depend on other debian packages exporting those libraries?
Since those files are already in the package
(https://packages.debian.org/sid/amd64/krb5-multidev/filelist), I assume
the intention is to link against the `.so` files distributed in the
`krb-multidev` package, and not to pull other deb packages. This could
be false, of course, if a user has already installed those packages and
for some reason the linker finds their SO files first, but I think
that's a bug in the definition of the krb5-multidev package, not this
implementation.
Plus, it has the added benefit that, if the debian package in question
doesn't include an appropriate .so file, we just don't create the
cc_import.
Fixes #123 #56 #66 #124