First, make sure existing compiler-generated RTTI from liblo-native-code.so is
found (so that catching bridge-synthesized exceptions in native code works with
libc++abi, which checks type equivalence by address instead of string
comparsion), by using the dlsym(RTLD_DEFAULT,...) mechanism as in the ANDROID
gcc3_linux_arm bridge case.  And second, if that should fail, synthesize the
type_info even if the included cxxabi.h doesn't provide the relevant type
declarations, by using copies from the ABI specification, as also done on other
platforms.

Instead of always having getRTTI fail and raiseException throw a non-synthesized
css::uno::RuntimeException("no rtti for type ...").  Which explains the mystery
discussed in the commit message of 312eeeee
"Switch Android armeabi-v7a to libc++/libc++abi/libunwind too", why the observed
misbehavior on x86 was so different from that on armeabi-v7a.

Change-Id: I9308654c5c2b88b4d27e0e8e9edda1849133a161
Reviewed-on: https://gerrit.libreoffice.org/65070
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>