Read MOSDocumentLockFile UTF-16 string data with same endianness

...as MSODocumentLockFile::WriteEntryToStream has written it to (i.e.,
always as UTF-16LE, assuming that is actually the right format to use).  The
discrepancy between writing and reading the string data appears to be present
ever since the code's introduction in 5db1e20b8b0942dac2d50f3cd34532bb61147020
"Introduce new lockfile handler for MSO like lockfiles".

This caused CppunitTest_svl_lockfiles to fail on (big-endian) s390x Linux with

> svl/qa/unit/lockfiles/test_lockfiles.cxx:578:(anonymous namespace)::LockfileTest::testWordLockFileRT
> equality assertion failed
> - Expected: LockFile Test
> - Actual  : 䰀漀挀欀䘀椀氀攀 吀攀猀琀

etc.

Change-Id: I97267aa14a3a926e7fd7bb1d2ce7d2de05d52a64
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103238
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>

0 files changed, 0 insertions, 0 deletions