hplip-3.{9,10}, blob lj-x86_32.so dynamically resolves its "statically" linked symbols

Some blobs internal static libraries are not actually linked staticaly so its symbols being dynamically resolved along all libraries linked or loaded with the blob and its caller which cause usage by the blob libraries with imcompatible API/ABI.

Particularly, blob has built-in library jbigkit version about 1.6 and it interfere with a system library with the same name (i.e. libjbig.so). The bug arise when that system jbigkit library is version of 2.0 which is binary not compatible with 1.x. This cause stack corruption in lj-x86_32.so and segfaults in hpcups.

Possible reproduction steps:
1. 32bit GNU/Linux OS.
2. Recent libraries jbigkit 2.x and libtiff 4.x build with jbig support (i.e. linked against system libjbig.so).
3. Blob lj-x86_32.so (mine has md5 sum 30bdf8c844508a53d80362f9eba670c5)
4. hpcups linked with that libtiff library.
5. Some execution of hpcups going through prnt/hpcups/ModeJbig.cpp:330 (for example, on printing with HP LaserJet p1006)

Expected results:
1. Function hp_encode_bits_to_jbig() uses symbol jbg_enc_init() which resolved and linked with system libjbig.so version 2.0 instead of built-in code.
2. jbg_enc_init() from sysyem library libjbig.so corrupts stack frame of hp_encode_bits_to_jbig() in blob erasing saved value of %ebx register of caller (jbg_enc_state structure in new version has some extra fields).
3. Just after call HPLJJBGCompress() at prnt/hpcups/ModeJbig.cpp:330 %ebx register not restored and set to zero.
4. Depending on compiler options (usually optimization needed, i.e. -O1 or -O2 for gcc) this could cause segfault later in the hpcups.