Whenever we have a libc major bump, we run the risk that dependent shared

Whenever we have a libc major bump, we run the risk that dependent shared
libraries will request a different (major) libc version from the one
requested by the binary itself.  For various reasons loading multiple libc
versions is not a good idea, and since the introduction of msyscall(2)
support, system calls will only work when called from one of the two loaded
libcs.  This really means that when we have a libc major bump, users must
update all dynamic executables and shared libraries in the system.

However, to ease this transition, change ld.so to only load the first libc
version that we encounter (in a breadth first sense) and substitute that
libc version for all further loads of libc, even if different versions are
requested.  This is done silently since I can't come up with a good warning
message.  In practice this means the libc version requested by the
executable itself will be loaded.  This means that shared libraries may
fail to load if they use a symbol that has been removed.  But given the
constraints, this is the best that we can do.  Even when we bump the
libc major, the set of changes is typically small and most binaries and
shared libraries will continue to run and allow the user to run pkg_add -u
without any fallout.

ok deraadt@, gkoehler@