fix(term, cli): Give details views a declared JSON shape

[JeanMertz]

A details view is rendered from a list of rows, each of which may or may not carry a label. details_json keyed its object by that label, so a row without one had no key to file its value under and was emitted as {"<value>": ""} — the data ended up in the object's key space, where a consumer has to parse it back out. jp attachment ls listed URLs that way, and any listing built on the same renderer would have too.

Deriving the shape from the rows instead is worse: it makes the output depend on what an invocation happened to produce. A listing holding one row would be an array and the same listing holding none an object, so every consumer needs a fallback for every field.

The shape is now a property of the view rather than of its data. Details is either Fields, a record of named rows that renders as a JSON object, or Items, a sequence that renders as a JSON array. A record cannot hold an unlabelled row and a listing cannot hold a labelled one, so neither can drift into the other's shape, and an empty view keeps its variant's form.

Conversation details are a record and read as they always did. Attachment listings are a sequence and now emit an array of values.

BREAKING CHANGE: jp attachment ls --format=json emits an array

The details field of a listing was an object whose keys were the listed values ({"file:///x": ""}) and is now an array of those values (["file:///x"]). A consumer reading keys should read elements instead. jp conversation show is unaffected: its rows are all named, so details remains an object keyed by field name.