Just merges some common code into setdefaults.

Change-Id: I2ba2c06425bcfe569fa147af713a064a145a2018
Reviewed-on: https://gerrit.libreoffice.org/65367
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>

Change-Id: I219d556f8e124cfe426cc1ac3c54da34eb7ef790
Reviewed-on: https://gerrit.libreoffice.org/49925Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>

* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
  MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
  goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
  to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
  mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
  results in inserting the english original so something can be found, now the
  standard fallback of using the english original from the source key is used, so
  partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
   xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
   xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
   content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
      com::sun::star::resource::OfficeResourceLoader
      com::sun::star::resource::XResourceBundleLoader
      com::sun::star::resource::XResourceBundle
    when translating strings via uno apis
      com.sun.star.resource.StringResourceWithLocation
    can continue to be used

Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a

exedir has to be in the c:/foo form, instead of /cygdrive/c/foo,
otherwise a native wrapper set by LO_TRACE won't understand it.

With this, it's possible to use DrMemory on executables invoked by
bin/run.

Change-Id: I5332342fdbf7d9e4859360dd7fbd3d74c149b2dc

Change-Id: Ifeeb839f82891057fe8e3e8fd6d537861d99f69f

Change-Id: I97d58f0e6780986356479279f91eba46951b1be0
Reviewed-on: https://gerrit.libreoffice.org/14783Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>

The app bundle in instdir is called either LibreOffice.app or
LibreOfficeDev.app.

Change-Id: I2e21656324cc7c52380fc86023bb95c848bb3962

(similar to our CPPUNITTRACE hook)

Change-Id: Iec4e8d4246ba7fca0afe5f9be6f6bcd9e0289e49

Change-Id: I9dd1ae23d27c5733770314ca907b5d36b749fd74

Amazingly Debian does not ship the realpath(1) from coreutils but has a
separate source package for it, and it's not installed by default.
Use readlink -f instead.

Change-Id: I6e97c851e6ab96dac08771145e2ab39dd9c11c22

The ../../../program/ links in the URE jar Class-Paths are a temporary kludge
(and juh.jar had lacked adaption for Mac OS X).

Change-Id: I2542d8a582866485dd61c05df3fc6b4b39a8403d

(and it is confusing if you pass a relative pathname argument to the program
you call via bin/run)

Change-Id: If8baef6d76e1f9ad7e5f2d361bd9b93fcbb76f7a

Change-Id: I5461a0d4e372260623ebb8833d60a9dc318757dd

...which does not have realpath(1), so just require CWD to match BUILDDIR there

Change-Id: I245241299d650c541f86cf440d3b57308c86d3fb

Change-Id: Ide3361fd5eba6462095cc45c0c99b1ab27a16262