Stop using -static-libstdc++

[NiLuJe]

Opting instead on shipping the TC's shared STL, as it's bound to be much, much saner.

Modified how Lua modules are linked to avoid passing absolute paths to shared libraries, because, depending on binutils version, this matters.

Also stopped lniking sdcv to a static libz outside of Android (where I'm not even sure why we do that for glib...).

---

This change is 

[NiLuJe]

Depends on koreader/libk2pdfopt#40 & koreader/crengine#488

[NiLuJe]

Also stopped lniking sdcv to a static libz outside of Android (where I'm not even sure why we do that for glib...).

Checking the history leads to #342, which limited the static mess to Android, and #317, which introduced it...

I'm pretty sure it's completely unnecessary nowadays, but, who knows...

[NiLuJe]

Hey, it almost worked first try on Android ;o).

[NiLuJe]

There, fixed Android.

Because it historically offered a choice of STL, everything is terrible:

• libstdc++.so exists, but is NOT a STL. It basically just implements new & delete (which appears to be enough for the nnsvg & xtext modules).
• So, you have to choose a STL. In practice, that's libc++ on Clang, and libstd++ on GCC; but, as stated above, they both have custom names, and since we're using a custom build-system, that means extra shenanigans to set that up.
• And, of course, the STL is never a system lib, it always has to be vendored (which sorta makes sense on Android, actually).

The downside to that last point is that it's probably built w/ debug symbols in the prebuilt TC because it's ginormous (5.5M, compared to my ~1.5M on plain Linux).

[NiLuJe]

Also stopped lniking sdcv to a static libz outside of Android (where I'm not even sure why we do that for glib...).

Checking the history leads to #342, which limited the static mess to Android, and #317, which introduced it...

I'm pretty sure it's completely unnecessary nowadays, but, who knows...

Oh, wait, I know why it was done this way. It's to deal with broken early (-ish) API levels where the dynamic loader is dumber than a bag of rocks (c.f., koreader/android-luajit-launcher#283).

[Frenzie]

It's to deal with broken early (-ish) API levels where the dynamic loader is dumber than a bag of rocks

Bionic is my mortal enemy.

[NiLuJe]

Made sure to link xtext, cre.cpp & CRe to the STL on Android, juuust in case.

(It doesn't get thrown out by --as-needed, so I'm assuming it's useful).

Also implemented the PRIVATE/PUBLIC switch for CRe linking as discussed earlier ;).

[NiLuJe]

Reviewed 2 of 6 files at r1, 3 of 4 files at r5, 1 of 1 files at r6, 2 of 2 files at r7, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @poire-z)