Issue #3620173: Add the term reference and vocabulary shapes

A term reference is the most frequent thing in these responses after plain text, and it is answered with three facts: what it is, what to call it, and where it goes. The hierarchical case adds the chain above the term, which is what breadcrumbs and category trees are rebuilt from by hand today in several places, each slightly differently.

The fragment carries both spellings of the label. This module writes the same triple as name in the branch and messenger listings and as title in the doctor and discount responses, and two of the forks do the same; a front end reads whichever one its page was written against. Answering with only one takes a name away from half the pages that display it, and the second key costs a front end that ignores it nothing.

Where a whole term is wanted rather than a reference to it, the work goes to the card shape. That is the same thing - a referenced entity rendered by a structure - and the version of it that already exists checks access, bounds nesting and collects cache metadata.

The vocabulary shape is the other half. Every site here has responses that are a vocabulary and nothing else, and each is a resource loading, sorting, translating and formatting the terms by hand; only the vocabulary differs. Its source is not a field, so the property names the vocabulary where it names everything else - and that needed the engine to stop discarding the source. It discarded both source and shape; the shape key is the engine's own dispatch and means nothing to a plugin, but a shape whose source is not a field has nowhere else to read it, and that is exactly when the field definition it is handed is NULL. The computed keys and the service-call source will need it for the same reason.

Sorting is done in the shape rather than in the query, because the loader re-sorts everything it hands over by weight on the way out, and a "sort by name" that is then re-sorted by weight is a setting that lies.

Closes #3620173