Two field reads throw away the cache metadata of what they built

Problem/Motivation

Two methods of the field accessor build something that has cache metadata of its own and hand back only the result.

getFieldTexts() reads the processed output of a formatted text field. 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. The processed string is then cached under the cache tags of the entity alone, so the response survives until the entity is edited while the thing the filter depended on has already changed.

getFieldLinks() resolves a link with Url::fromUri($uri)->toString(TRUE) and keeps only getGeneratedUrl(). What it drops says that the address depends on the alias of a page and on the page itself, so a response goes on publishing a link to a page that has moved or been deleted.

Neither is visible in testing: the response is correct when it is built and wrong only after something else changes. Both are read by the resources the module ships today.

Proposed resolution

• Give both methods a way to hand the cache metadata back with the value, and make the callers collect it into the response they are building.
• Render the processed text rather than reading it, so that what the filters bubbled is reachable at all.
• Kernel coverage for both: a format whose filter adds a cache tag, and a link to an entity, asserted through a resource response rather than through the accessor alone - the bug is that the metadata does not arrive, and only the response can say whether it did.
• Keep the per-entity caching the text read does. It is there because the filters are expensive, and the fix is to cache the metadata with the string rather than to stop caching.

Remaining tasks

Everything.