so it does nothing on platforms where soversions are not used

renaming previous test to XRangeNames
new test for XRangeName

Turns out our encrypted zip package code writes out mismatching
compression methods in central directory and local file headers -
so not only be lenient towards the apple bug (n#653688), but also
ours (i.e. keep not comparing nMethod with nHow).

While fixing n#653688, turned out we write method=STORED into local
file headers, and method=DEFLATED into central directory structure
for encrypted ODF. Damn side-effects - fixed as hopefully intended
here.

Clearly this iteration and reading of the referer, that is then
subsequently not used at all by the method, can go.

This fixes cross-compiling from Linux to Android. My guess is that the
build system nowadays, when building the cross_toolset (for the build
platform), sources Env.Build.sh in an environment where Env.Host.sh
has already been sourced. So, if Env.Host.sh exports SYSBASE, that
stayed in force also after sourcing Env.Build.sh, with predictably
horrible results.

For some reason it didn't hurt cross-compiling from Mac OS X, which is
why I hadn't noticed.

This allows for setting a SONAME and version script, which is required
for UNO runtime libraries where we want to maintain a stable ABI.

The old build system did apparently not set an SONAME on MacOSX or
Solaris, so don't do that here either.

The option -P seems to be supported by a lot of ancient cp
implementations, let's hope it actually works.

* Reintroduced logic in PrepareQueryItem::operator() that got lost during
  rework of ScQueryEntry.
  * ScQueryParamBase::FillInExcelSyntax() and the calling
    lcl_createExcelQuery() create query entries always as ByString, that
    needs to be converted to ByValue if appropriate.

Enable it by default on MacOS X

Apparently on Windows the SAL_DLLPUBLIC_EXPORT does not work for unknown
reasons, so use the old mapfiles on that platform.

Should fix regressions from 1fb5eb21, 48dbaa51, a9da5a0b.

It turns out even quite recent gdb (7.1) reportedly does not
support DWARF4, moreover while the produced binaries are smaller,
faster and make gdb initially use less memory, this quickly ceases
to the case as soon as one actually does anything in gdb.
Presumably the DWARF4 handling in current gdb is very inefficient
(http://sourceware.org/bugzilla/show_bug.cgi?id=13498).

This reverts commit 5214f784.

Conflicts:

	solenv/gbuild/platform/WNT_INTEL_GCC.mk
	solenv/gbuild/platform/unxgcc.mk

+ Checks out-of-bounds accesses in
  ScFormatRangeStyles::GetStyleNameIndex() and
  ScRowFormatRanges::AddRange() and prevents crashes.
- The real cause seems to be some style row/repeat miscalculation
  elsewhere, further investigation would be necessary.