First of all, LD_LIBRARY_PATH must not affect the make executable called for the
firebird build.  That would cause problems when that make executable depends on
system versions of dynamic libraries that also happen to be available as LO-
built versions on LD_LIBRARY_PATH:

> make: symbol lookup error: /data/sbergman/lo-san/core/instdir/program/libfreebl3.so: undefined symbol: __asan_option_detect_stack_use_after_return
> make: *** [/data/sbergman/lo-san/core/external/firebird/ExternalProject_firebird.mk:41: /data/sbergman/lo-san/core/workdir/ExternalProject/firebird/build] Error 127

For that, gb_Helper_extend_ld_path is now tunneled to the relevant places in the
firebird build, where executables are called that use firebird's
UnicodeUtil::getConversionICU
(workdir/UnpackedTarball/firebird/src/common/unicode_util.cpp) to dynamically
load icu libraries.  (Similar to 3a281828
"external/liblangtag: Tunnel LD_LIBRARY_PATH to where it's actually needed".)

Then, what appears to work is to disable firebird's global operators new/delete
(so that ASan's versions kick in).

MemPool::{alloc,release}Raw would still be called at start-up through
Firebird::GlobalPtr<Firebird::Mutex, (Firebird::InstanceControl::DtorPriority)3>
::GlobalPtr() calling Firebird::GlobalStorage::operator new(unsigned long), but
there is already provision to avoid those functions' heavy machinery for the
USE_VALGRIND case.

DEBUG_GDS_ALLOC (which would enable other inopportune overloads of global
operator new/delete) needs to be disabled in a somewhat contorted way, because
8ea07101 "external/firebird: Work around
operator new alignment violations" might explicitly set it from the outside,
which we need to undo for ASan builds.

`make check screenshot` encountered one alloc-dealloc-mismatch (already during
building firebird itself) that needs a patch to src/jrd/SimilarToMatcher.h.

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