fix: write xml:space="preserve" for inline strings

[closset703]

Fixes #624.

Cell.write() now emits xml:space="preserve" for plain inline strings, matching what StringCache.write() and RichText.Run.write() already do. Without it Excel trims leading and trailing whitespace from cells written through inlineString(int, int, String), so the same value is kept or trimmed depending on which string API the caller happens to use.

-                w.append("<is><t>").appendEscaped((String) value).append("</t></is>");
+                w.append("<is><t xml:space=\"preserve\">").appendEscaped((String) value).append("</t></is>");

Behaviour change

This changes output for existing users: values that Excel used to trim are now kept. Anyone who relied on that trimming would have to trim before writing.

My reading is that this matches the direction already set in #475 — "Preserve white spaces by default. The user just needs to trim the strings themselves in case they don't want it." — and that this PR only applies that policy to the path it missed, rather than introducing a new one. Flagging it explicitly so you can confirm, since it does alter existing output. Happy to make it opt-in instead if you'd prefer that.

Test

stringCellsKeepEdgeWhitespace asserts the attribute on all three string paths (shared, inline, rich). Excel's trimming cannot be reproduced in a unit test, so the test verifies the emitted XML instead — it fails without the one-line change in Cell.write() and passes with it.

The workbook part is read through ZipFile rather than ZipInputStream, because the streaming zip records entry sizes in a data descriptor that ZipInputStream rejects.