Design defense in depth for interpolation hazards

[japhb]

A significant percentage of security issues across the software industry are caused by interpolation hazards: cases where a bad actor can influence the content of variables interpolated or concatenated into strings. The most well-known of these is probably the SQL injection ("Bobby Tables") attack, but a fairly large number of attacks are possible against TUIs directly. This includes the insertion of unexpected escape sequences and misleading line breaks, among many others.

It is expected that T-W apps will be rendering a LOT of strings, many of which will be partially or totally controllable by an attacker. Thus to be a good citizen, T-W itself should provide significant defense in depth against these attacks, and make sure that the easy way of operating with strings is also the correct and safe way to do so.

• Strings in the Raku source should be single (or q/Q) quoted (completed as of c63bc1a)
• Translated strings cannot interpolate unless the source string is marked explicitly as interpolatable
• Strings are not parsed for span markup unless explicitly requested
• Any displayed string must be defanged of control characters of all sorts (including e.g. rendering direction overrides)
• Any displayed string must not allow invalid or unassigned Unicode codepoints
• A single render span either contains only a single interpolation (and no other content), or no interpolation at all
• Content of any type must be defanged before conversion to render spans
• The renderer must not allow non-defanged content through (and thus semantic spans and render spans must be different)
• String markup syntax should make it difficult to make mistakes that break the above
• All of the above should be codified as part of a Coding Standards doc (see Create a Coding Standards document #10)

[japhb]

Sketch of new text content model that addresses several of this issue's tasks: https://github.com/japhb/Terminal-Widgets/blob/main/lib/Terminal/Widgets/TextContent.rakumod . This still needs to be tied into the rest of the codebase before those tasks can be considered complete. (And of course, some of the functionality is just stubbed right now.)

[japhb]

Did a pile more work on the new TextContent model, but can't push yet because I'm finding some downstream issues that I need to clear up first. Still, progress continues.

[japhb]

A bunch more work done on this one today. I was able to push at least, but I'm still not ready to make a release based on it -- it's going to require some minor compat-breaking, and I'd rather get it closer to right than break compat two releases in a row if I can avoid it.