plus further work in i18npool to make that build

adapt i18npool to ICU 53 upgrade, fdo#77071

Korean charset collator can't be built from ko_charset.txt because of

"The runtime code decomposes Hangul syllables on the fly, with recursive
processing but without making the Jamo pieces visible for matching. It
does not work with certain types of contextual mappings."
"While handling a Hangul syllable, contractions starting with Jamo L or
V would not see the following Jamo of that syllable." (this is where we
bail out already with the first syllable of ko_charset.txt)
Another condition to fail is described as "A contraction ending with
Jamo L or L+V would require generating Hangul syllables in
addTailComposites() (588 for a Jamo L), or decomposing a following
Hangul syllable on the fly, during contraction matching."

Excluded the file from the build for ICU >=53 and hope that ICU in the
mean time handles Korean collation correctly.

Additionally, ICU 53 took ages (if it would had finished at all) to
build the collator from zh_TW_charset.txt because of the \u#### escaped
notation. Converted the file's content to characters using
http://www.rishida.net/tools/conversion/

Change-Id: I64213214b4870e7077f72b95fee1ddc9782c2b21
Reviewed-on: https://gerrit.libreoffice.org/9204Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>

Change-Id: I3b14447130c32d4b21010380f7901c0d20004ffc

This commit:

 http://cgit.freedesktop.org/libreoffice/core/commit/?id=805c6101b3427cc98b53f1c48f22f705206c384d

make LibreOffice 4.2 (and AOO 4.1) widely incompatible to previous
versions. We should thus update the reference version to 4.1 as that is
the version we are least incompatible with. Extension developers are
encouraged to use LibreOffice-minimal-version instead anyway, instead of
the obsolete OOo versioning. see:

 https://wiki.documentfoundation.org/Development/Extension_Development
 https://gerrit.libreoffice.org/gitweb?p=sdk-examples.git;a=commitdiff;h=61f9ca7b18de1adc58cf5d7cb295ba81eb3e5d92;hp=20b8edc74b846db6d143a9e327fb7f7eb2c1fb77

Change-Id: I8275a8244d642100d7b3bc17aa0b12ae7d63e583
Reviewed-on: https://gerrit.libreoffice.org/8852Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

Change-Id: Ie5b6ffee07b6e5ebf922bad1b4a268ff636412c9
Reviewed-on: https://gerrit.libreoffice.org/8853Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Tested-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>

Change-Id: I44669bce64ee20a907e85d7dcf79ce20e85d1360

Change-Id: I393aadc30190177b75f7f6b723c000b583697c37

Change-Id: I0ee0fd95b88d27d2a2d66fa82f489a78d2893b84

Change-Id: I0b57ff0ea059e924f6508da5f76b5e8e7ed8cbf3

Change-Id: I06531e828d7a110a8de6520737935550d250dff8

Change-Id: I1e34ee6d62c18a5595afac939f8363085cb88bad

Change-Id: Id63e45f65dbcbbd4d8e861405670369a0fa8d70e

Change-Id: Ib24ca6323615e8a8ba704295d9a9fe92c80a1ae1

Change-Id: I9da96ba05b0fb628ac497304c4e2aa987da0eab8

Change-Id: Ie9d104df391fd0581943a1c91421cfc08c95709e

Change-Id: Id2c8432aba3268f7ffbe26c13e81025f2e047865

Change-Id: I14f6ef8fe0e58859f29b2ec68e5fd563c98cb199

Change-Id: I3f8700f22cee6990791d50475973e91a092260d5

Things are a bit more complex in cut mode than what this method can handle.

Change-Id: Idadee23beff08c2df89d47bb237e8a2d2fd69dab

Change-Id: I971e7ea2535138eb4ac901c227c72a50578746a8

Change-Id: I74f5e25a05ca3c4c0259dd7f33da57a9e0790caa

(regression from 6af1e845)

Change-Id: I22dd77fe9bb03f2cf4ce4518ef12c566aad66785

Change-Id: I7fec37c5edd42d974bddb4abbecb0d2b3dd86f14

so the graphic gets swapped out Xms after the last use and not Xms after
initial creation regardless of if it got used a moment earlier.

Change-Id: I1458f307d090ecd8d8d031b545f23e78bf1bcb67

Change-Id: Ie781c2534cb41104dd3d91d4370639e98baa8112

Change-Id: If4e8ddfa0a4dcb9875ce82fc82d196ff3dbd9657

Change-Id: I555c773b0dcc90c8efba5fd7d48b22278f2ef5a5

Change-Id: I9102caec1fec680e55e0ca66a0e1b02f41df5828

In 4.1 this loops because the input is truncated to 64k length; try to
avoid looping when the input is invalid and the terminating ">" cannot
be found.

Change-Id: I9261d9350f84ab366b822addde725645a46be830

This part of 13a34f4c was correct. The main
thread will deadlock on the yield mutex if the calling thread does not release
it before waiting on the main thread.

Change-Id: I6692473457258b791c131e8bdb459b06b01550f7

otherwise signing (at least on windows) fails because files are in use

Change-Id: Ida6a7d43dc74eb278fd79410b9c0a60f823c5933
Reviewed-on: https://gerrit.libreoffice.org/9176Tested-by: David Tardon <dtardon@redhat.com>
Reviewed-by: David Tardon <dtardon@redhat.com>

Change-Id: I4bbd62b153f7e4b7769b1e1eeb65ce801e57ff5b

Change-Id: I09534eab67c0ae38cd6965c3b63227d92b72c646

Change-Id: Ice39630a7991bf037842557e76bfb95600c57ea3

Change-Id: I30c9449901cd96b74141dd511cabff3c5b9201bc

Change-Id: I2611c840e572d1b46deefc5ce888721820a2bd40

Change-Id: I9a86030d988473ac56ee1c6c1325b1eede2ba010

Change-Id: Ic632e75e35bc14b714a30e71eb9957d3f949cbf5

Change-Id: I837094aaf9f04c189296417d77391e3f56604616

Change-Id: Ia74bb69ec3ed269d4a73633d470b2d3247741d58

Change-Id: Ib4de734a2703060174f618a8a2b313cd92e82cf2