refactor(reader): type the reader surface with ReaderContent

[usamaiqb]

The reader surface took text: Any and probed it with is Spanned at four sites. Retype it to the sealed ReaderContent, so the question becomes which of three known shapes it is rather than what it could possibly be.

ReaderContent.Spans carries a CharSequence rather than a Spanned, because unstyled text is a real case and not a placeholder for one: the raw view and the plain-text format both hand over a String, and wrapping those in a SpannableString copies up to the maximum file size for no styling benefit. PlainTextFormat was paying that copy to satisfy the old signature and now hands its input straight through.

RenderedTextView opens with an exhaustive when that yields the text to draw, so a shape it cannot render cannot gain a producer without a decision at that site. One text as? Spanned below it feeds every consumer that needs marker spans -- the span scans, split-mode detection and the split update pass -- which is where the narrowing genuinely belongs. Search keeps its own, for the same reason: counting matches and painting them with spans is a property of that implementation, not of the reader.

Both casts at the format boundary go. The view models, the render cache and the editor preview all carry a ReaderContent now.

The detekt baseline entry for RenderedTextView is re-keyed for its new parameter list rather than regenerated.