v0.5.0 — ODS spreadsheets

Read ODS spreadsheets, not just ODT

Parse now accepts an .ods package. A spreadsheet is the same container
as a text document — the same ZIP, the same content.xml, the same
table:table/-row/-cell elements — inside an office:spreadsheet body
instead of an office:text one. Each sheet comes back as a level-1 Heading
carrying its table:name, followed by the sheet's Table.

Write still always produces ODT. This is additive — nothing about the ODT
round-trip changed, which is why it is a minor.

Why this was worse than a missing feature

⛔ The cost was silent. An .ods parsed without an error into a document
of no blocks, so a conversion handed somebody an empty page and no reason for
it. An empty answer and a refusal are different things, and this was neither.

A repeat is a count in a FILE

table:number-columns-repeated and -rows-repeated are honoured — and capped,
at 1024 columns and 65536 rows, because materialising what they ask for is an
allocation the input decides. The trailing padding every spreadsheet writes
to square its rows off is dropped, but only from the end: an empty cell
between two full ones is a gap in the data.

OpenSSL's own lifecycles.ods pads to 1024 columns and asks for 1 048 559
repeated empty rows. Read as written, its six sheets are 91 rows and 14
columns.

Measured on real files

Four third-party .ods written by real spreadsheets: 4 read, 0 refused, 0
empty. End to end through go-richdoc/latex/pdf, OpenSSL's workbook typesets
to a 5-page PDF whose six sheet names poppler — a judge independent of this
stack — finds as numbered headings.

100% statement coverage, go vet and gofmt clean, 11 checks green across
10 architectures, and 10 mutations against the new decisions all caught.