mkdumprd should restore ld.so.cache rather than re-generate it

Issue

• The following code is used in mkdumprd (and aparrently kboot also) to temporarily run ldd with a different ld cache. However it makes some bad assumptions.  The following code assumes that running 'ldconfig' is the correct way to restore the original ld.so.cache.  However, in the common use case mkdumprd and thus ldconfig is being run out of rc3.d/S20 during the first boot of a system.  This effectively breaks any ld.so.conf entries which are only available via autofs or network filesystems. In our case, /opt is an automount point, and is empty before S28autofs runs.  Dell agents hard-code /opt paths into many locations, including the ld.so.conf.d entries they create.  Which means that despite any setup steps, kdump breaks the dell software on the first boot into a kdump-enabled runlevel.

      #find the shared libraries.  this snippet taken from kboot
      TEMPLDCFG=`mktemp`
      for lib in `ls /etc/ld.so.conf.d/* 2>/dev/null | grep -v kernelcap`
      do
          echo "include " $lib >> $TEMPLDCFG
      done 
      /sbin/ldconfig -f $TEMPLDCFG
      kdump_libs=`for n in $bin; do 
          ldd "$n" 2>/dev/null | tr -s '\011' ' ' | 
          sed 's/.*=> *//;s/^ *//;/ *(0x.*)/s///p;d' 
      done | sort | uniq | sed '/^ *$/d'`
      /sbin/ldconfig
      rm -f $TEMPLDCFG