Issue #3620181: Add the processed text and plain text shapes

Long text has two problems that a read of the field does not solve, and they are the reason this is a shape.

The first is cache metadata. A format is a chain of filters, and a filter may say that its output depends on something the entity does not: a media item it embedded, a configuration object it read, a time after which it goes stale. Reading the processed value off the field throws all of that away, and the response is then cached until the entity is edited while the thing the filter depended on has already changed. So the text is rendered rather than read, and what the filters bubbled travels out with the fragment.

The second is addresses. A picture uploaded into an article is stored as a path relative to the back end, which resolves for a browser on this site and for nobody else. Those are made absolute against the address the site is read at. Links to pages are deliberately left alone: a page link belongs to the front end's own router, and making it absolute would send a visitor out of the application. Where there is no address to build against - nothing configured and no request to take one from - the text is answered with as it is, because half an address is worse than a relative one.

A field with a summary answers with both parts, named. Which of the two a page shows is that page's business, and picking one here would decide it for every page on every site.

The plain string shape is the opposite: it does nothing except hand back what the editor typed, with an optional shortening at a word boundary - because the alternative is every front end shortening the same string differently and one of them cutting a word in half.

Closes #3620181