Take core 7.1.0, and edit with the editor the page now carries

[andiwand]

In core 7, editing is part of the rendered page. The page owns the edit mode, the operation log, undo and the refusals. A pdf page also gets an annotator. This PR drives that page from the app, and it takes core 7.1.0, which has the fixes and additions this PR needs (see below).

What changes

• The core bump. CoreLoader follows the API breaks: DecodeOptions, Html.translate without a cache path, Document.edit, and csv and markdown files that hold a text file rather than being one.

• What can be changed is one answer from the core. CoreLoader.editingOf returns an EditingKind: DOCUMENT (odt, docx, pptx), SHEET (ods, xlsx), TEXT (txt), ANNOTATION (pdf), or NONE. The file answers for itself, so a decrypted document or a repaired pdf says no.

• No second render for the edit mode. A document that can be written back is rendered with its editor. The edit button calls odr.editing.enable(), so the reader stays where they were.

• The page decides, and the app only listens. PageView injects editing-bridge.js on each page load. The script points the page's callbacks (onEditChange, onEditRefused, onSelectionChange, onCellsStale, onAnnotationChange) at PageView, and turns on markOnSelection. It holds no logic. A pdf tool button calls odr.annotation.press or recolor, and the page decides what the press does to a selection.

• No document stays open between the render and the save. CoreLoader.writeEdits opens the cached copy again and applies the payload with the call for its kind: Document.edit and save, TextFile.edit and save, or PdfFile.annotate.

• The UI follows the website's viewer, and matches OpenDocument.ios 3.10.0 #195. The bar of the edit mode holds save. Under the bar, a row holds the tools, with undo and redo at its end:

  • a document: bold, italic, underline, strikethrough, text color (opens the colors), highlight (toggles; its arrow picks the color) and text size, which shows the size of the selection;
  • a pdf: highlight, underline, strike out, squiggly and draw. Each tool has its own color and an arrow to pick it. A tool tapped with text selected marks the selection once and arms nothing. A pdf has undo only;
  • a sheet or a plain text file: undo and redo.

  The color bars follow the selection. Both apps offer the same colors. iOS adds "Other color…" from the system picker, which Android does not have. A save stays in the edit mode.

• Leaving the edit mode with unsaved edits asks to save or discard them. Before, closing the bar dropped the edits without a question.

• A refusal from the page (a formula cell, a range over a picture, and so on) shows as a snackbar in our own words. When an edit leaves formula cells out of date, a snackbar shows their count each time the count grows.

Pro and lite

The same line as OpenDocument.ios #195. Features.advancedEditing comes from ADVANCED_EDITING, next to LINKS_ADS in Linked.kt. It is false in lite, and true in pro and foss (which share noAds). Features.offersEditing is the one list of what each edition edits.

	lite	pro, foss
text inside one paragraph (odt, odp, odg, docx, pptx)	yes	yes
sheet cells (ods, xlsx)	yes	yes
plain text (txt)	yes	yes
split or merge a paragraph, formatting	tools shown behind a "Pro" badge; offers Pro, once per edit	yes
mark up a pdf	the button offers Pro	yes

The Edit button depends on the core's answer in every edition. The offer is a dialog with "Get Pro" and "Not now". It is reported as pro_gate_shown / pro_gate_tapped with the feature, as on iOS. Lite renders a text document with HtmlEditingScope.PARAGRAPH, so the page itself refuses an edit that reaches past one paragraph (outOfScope).

This is different from OpenDocument.core/offline/feature-gate-plan.md, which put sheet cells and plain text on the Pro side. We decided to make them free in both apps.

What core 7.1.0 brings to this PR

• fix(html): record what an Android keyboard types into a document OpenDocument.core#905: text from an Android keyboard is recorded. In 7.0.0, Gboard keeps a composition open on the word under the caret, and document.js lost the edit. The text showed in the page, but getOperations() stayed empty, so a save wrote the original document. Enter could also split a paragraph in lite, where the scope must refuse it. This blocked the PR.
• fix(html): one undo takes back a whole edit OpenDocument.core#904: one undo takes back a whole edit, for example an Enter inside a run.
• feat(html): the pdf annotator reports its changes and takes a tool press OpenDocument.core#906: odr.onAnnotationChange and odr.annotation.press / recolor. The core now does the counting of marks and the tool-press logic that editing-bridge.js did. iOS and the website have the same logic, and can drop it too.
• feat(api): a plain text file edits and saves with the names of Document OpenDocument.core#902: TextFile.edit and save replace the deprecated writeEdited.

Checked

On core 7.1.0, on an API 31 emulator with Gboard:

• spotlessCheck, assembleDebug (three flavors), lintProDebug, lintLiteDebug, lintFossDebug and testProDebugUnitTest pass.
• CoreTest: 21 of 21 pass, with save round trips for odt, docx, pptx, pdf annotation and txt.
• MainActivityTests: 16 of 16 pass in pro and in lite. They check each edition's side of the gate: a sheet edits in both, a pdf offers Pro in lite, and the scope is paragraph in lite.
• By hand in pro: text typed with Gboard into an odt is in getOperations() as setText, and Enter is splitParagraph. Leaving the edit mode asks about the unsaved edits, and Discard leaves a clean page.
• By hand in lite: typed text is recorded. Enter is refused (no splitParagraph) and offers Pro.
• By hand on a pdf: a tool tapped over a selection marks it once and arms nothing. A tool tapped without a selection arms, and a second tap disarms. Undo removes the mark and disables the Undo button.
• On core 7.0.0, before the bump: 94 instrumented tests, and a pdf and a sheet saved through the picker and opened again.

New strings are translated into all 19 locales. ga, hi, ko and et have no iOS text to follow, so they need a review by a native speaker.

Not in this PR

• Store screenshots per flavor. The UI now differs between lite and pro, so the screenshot set has to split. That is the next step.
• The Play listing and the house ad do not yet say what Pro edits (step 3 of the plan).