Allow for query result display customization

[tkuhn]

Query results should have be displayed in a way customizable, e.g. via HTML <template> elements.

[tkuhn]

Sketch for later — HTML-<template>-element approach (server-side):

Authoring. A View nanopub carries an HTML snippet via a new predicate (e.g. kpxl:hasResultTemplate). The snippet is real HTML so authors can preview it standalone. Selected via a new viewType (e.g. TEMPLATE_VIEW) so existing TABULAR/LIST views are untouched.

Placeholders. {{col}} substitution in text nodes and attributes; values HTML-escaped at substitution time. For repeats: <template data-for="authors_multi_iri">…</template> clones its body once per item with {{value}}, {{label}}, {{index}}, {{first}}, {{last}} in scope.

Multi-value handling. The existing column suffixes already encode this — _multi_iri is whitespace-split, _multi_val/_multi are newline-split, and a companion _label_multi column holds labels by index (see QueryResultTable.java ~L188–235). The renderer pre-zips these into a List<{value,label}> so templates just loop. Plain _iri columns also expose a sibling .label instead of being auto-wrapped in NanodashLink — the author writes the <a> themselves.

Pipeline. Parse template once with Jsoup (new dep) → per row, clone DOM, expand <template data-for>, substitute {{…}} → serialize → run through existing Utils.sanitizeHtml() → emit as a Label with setEscapeModelStrings(false). Note: most HTML sanitizers strip <template>, so template expansion must happen before sanitization.

Out of scope for v1. Conditionals (data-if), nested-multi (works structurally but unspecified), per-cell helpers beyond label/IRI. Easy to add later if real templates demand them.

New rendering class slots in next to QueryResultTable / QueryResultList; no changes to ApiResponse/ApiResponseEntry.