More informative logging in codeSnippet()

Change-Id: I51bceba0918928812daca3a2c92633b6998b380c
Minor logging change

Change-Id: I2d25c7c196d0386a1c38fa55746370a84c2a2398
Hacky workaround for non-working C++/UNO bridge for arm64 iOS

I haven't managed to get the C++/UNO bridge to work for 64-bit iOS
code yet. I think I understand the calling convention and the
parameter marshalling etc might even be correct now. But something
goes wrong in the dynamic creation of type_infos and throwing of
exceptions. 64-bit iOS code uses a different unwinding mechanism than
32-bit iOS code, I think, which could be related.

Quite possibly there is also an unintended compiler feature (or dare I
say bug?) in Apple's Clang for arm64 that affects this: The typeinfos
are generated as private_extern symbols in arm64 code (instead of as
normal extern in armv7 code), thus the dlsym() thing to look up
typeinfos doesn't work.

Note that as we don't support any Basic, Java or Python on iOS anyway,
the C++/UNO bridge is not used for much. Actually, the only use of the
bridge at least in the TiledLibreOffice test app seems to be to throw
exceptions. Fun, huh? As the actual types of exceptions thrown seems
to be a quite small set, just hack it and throw the appropriate
exception directly... The only places where exceptions are thrown
through the bridge that is used in the test app seems to be the two
cancelCommandExecution() functions in ucbhelper.

(It would be nice to change the ucbhelper API to not use exceptions
for non-exceptional conditions, but that's another thing...)

Change-Id: Ifd1861ccbba23d3b138e82400f2b7d80baf0215a