...otherwise preload.cxx in juh.dll will not be able to find them
via osl_getFunctionSymbol.  What apparently happens is that JNICALL expanding
to __stdcall decorates symbol names with _...@NN.  This likely was hidden in
pre-gbuild times thanks to the use of def files.  (On a side note, the JVM
appears to contain special code to find syms for native methods in both
decorated and undecorated form; that explains why it picks up the decorated
symbols from juh.dll just fine.)

There is no need for the functions in juhx.dll (called from the juh.dll wrapper)
to adhere to JNICALL (in fact, things would likely be easier to maintain if the
juhx.dll functions also used different names than their juh.dll wrappers).
However, what complicates this patch is that for DISABLE_DYNLOADING, the juh
wrapper and its preload.cxx is elided, and the code that would normally go into
the juhx library goes into the juh library (and thus needs to stick to JNICALL,
and also needs to use the right function names).

(cherry picked from commit 96488510)
Conflicts:
	javaunohelper/source/bootstrap.cxx
	javaunohelper/source/javaunohelper.cxx
	javaunohelper/source/preload.cxx

Change-Id: I66611648f1f79f57f0c1b23fb7a801da2d7b86c5
Reviewed-on: https://gerrit.libreoffice.org/3455Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>