Add separate mechanism to load libc

[frankvanbever]

I'm currently trying to fix an issue with python-iptables in Buildroot where we encounter issues when attempting to import 0.14 due to the way dynamic libraries are loaded. (Buildroot bug report is here: https://bugs.busybox.net/show_bug.cgi?id=12271)

First some important information for context:

• Buildroot does not support a toolchain on the target. This is a design decision. Due to this ctypes.util.find_library() does not work.
• Buildroot supports not only glibc but also uClibc and musl. These do not necessarily install a symlink of themselves to libc.so but do have well defined sonames.

Afaict there are 2 locations in the code where libc is loaded:

1. The first one is here This poses a problem for Buildroot given that by default not all libc's install the given symlink.
2. The second one is here libc.so.6 is the soname of glibc.This makes the package explicitly depend on glibc which would be unfortunate given that the package can also be used with the alternatives.

Given that the soname is well defined and there's already a precedent of using the soname directly the fix I came up with would be that finding the libc would be handled in a special case, split off from the other find_library() code i.e. a dedicated function that would explicitly check for the existence of a supported libc by soname in the case where ctypes.util.find_library() returns None.

The provided patch solves the issue within Buildroot for all aforementioned C libraries and should not impact systems where ctypes.util.find_library() works.

If this would not be an acceptable fix I'd like to at least open a discussion about how we could fix this, rather than maintain this patch out-of-tree.

[coveralls]

Coverage decreased (-0.02%) to 58.485% when pulling e3557528d7cdcdc2c579212be8837bc9b54635a4 on essensium-mind:find-libc into e606d413ddf7c10061f8d4556356247ffba0deaf on ldx:master.

[ldx]

Looks good, thanks!