package/pkg-generic.mk: also replace /lib by STAGING_DIR/lib in .la files

package/pkg-generic.mk: also replace /lib by STAGING_DIR/lib in .la files

After the staging installation, we replace a number of paths in libtool
.la files so that those paths point to STAGING_DIR instead of a location
in the build machine.

However, we replace only paths that start with /usr. And it turns out
that the linux-pam package is configured with --libdir=/lib (linux-pam
seems to always be installed in /lib rather than /usr/lib).

Due to this, libpam.la contains the following line:

  libdir='/lib'

When building a configuration that has:

 - BR2_ROOTFS_MERGED_USR=y
 - BR2_PACKAGE_LINUX_PAM=y
 - BR2_PACKAGE_POLKIT=y

on a system that has its system-wide PAM library installed in /lib,
the build fails with:

/lib/libpam.so: file not recognized: File format not recognized

For some reason, libtool searches only in STAGING_DIR/usr/lib, but
when BR2_ROOTFS_MERGED_USR=y, STAGING_DIR/lib points to
STAGING_DIR/usr/lib, so libtool finds libpam.la. And this libpam.la
contains a bogus libdir='/lib' path. libtool then goes on, finds
/lib/libpam.so, and links with it, causing the build failure.

By doing the proper replacement of libdir='/lib', we have a correct
libpam.la, and solve the build issue.

There is no autobuilder failure associated to this issue, as it
requires /lib/libpam.so to exist. This is the case on ArchLinux, on
which Xogium reported the issue, which can also be reproduced in an
ArchLinux container.

Reported-by: Xogium <contact@xogium.me>
Cc: Xogium <contact@xogium.me>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Yann E. MORIN <yann.morin.1998@free.fr>
[yann.morin.1998@free.fr:
  - tested by manually creating a symlink to libpam.so in /lib
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>