Closes: #XXXX
Refs: Agoric/agoric-sdk#5401

## Description

We often need to see the deep contents of a Passable. Indeed, this was
kicked off by a slack thread about wanting to quote
```js
M.splitRecord(
    harden({
      assetKind: M.or('nat', 'set', 'copySet', 'copyBag'),
      decimalPlaces: M.and(M.gte(-100), M.lte(100)),
    }),
  )
```

This PR provides a `qp` function meaning "quote passable". You can use
it where you'd use `q`. It produces a quasi-quoted Justin expression of
the form in which the passable would be passed. For example, the `qp` of
the above pattern is

```js
`makeTagged("match:splitRecord",  [
  {
    assetKind: makeTagged("match:or", [
      "nat",
      "set",
      "copySet",
      "copyBag",
    ]),
    decimalPlaces: makeTagged("match:and", [
      makeTagged("match:gte", -100),
      makeTagged("match:lte", 100),
    ]),
  },
])`
```

### Security Considerations

Unlike `q`, `qp` does not lazily postpone rendering the expression into
Justin. `q` can do this easily because it is inside the `'ses'`
assert.js module and can use the rights amplification available only
there. `qp` depends on `'@endo/marshal'` which is several levels up from
`'ses'`. Rather than expose these rights amplification powers (or
several other kludges that failed), I just made `qp` non-lazy. Thus
there are no security implications.

### Scaling Considerations

Because `qp` is not lazy, simply constructing an error with `Fail` or
`makeError(X...)` will pay all the cost of rendering to Justin, whether
or not that error is ever used.

### Documentation Considerations

Because Justin is a subset of HardenedJS, the Justin expressions
produced by `qp` can be used in documentation if needed. Though see
Compatibility Considerations below.

### Testing Considerations

- [ ] Only minimal tests written for `qp`. We should also write a test
that loops through all the `jsonJustinPairs`, just as other Justin tests
do.

### Compatibility Considerations

Using Justin with symbols exposes in the rendered string how Justin
currently represents passable symbols. That changes in #2793. Whichever
of these gets merged first, the other will have to reconcile merge
conflicts. And any saved Justin strings containing that old Justin
representation will need to be updated or marked stale.

### Upgrade Considerations

Other than the Compatibility Considerations above, none.

- [x] Update `NEWS.md` for user-facing changes.

Closes: #XXXX
Refs: Agoric/agoric-sdk#5401

## Description

We often need to see the deep contents of a Passable. Indeed, this was
kicked off by a slack thread about wanting to quote
```js
M.splitRecord(
    harden({
      assetKind: M.or('nat', 'set', 'copySet', 'copyBag'),
      decimalPlaces: M.and(M.gte(-100), M.lte(100)),
    }),
  )
```

This PR provides a `qp` function meaning "quote passable". You can use
it where you'd use `q`. It produces a quasi-quoted Justin expression of
the form in which the passable would be passed. For example, the `qp` of
the above pattern is

```js
`makeTagged("match:splitRecord",  [
  {
    assetKind: makeTagged("match:or", [
      "nat",
      "set",
      "copySet",
      "copyBag",
    ]),
    decimalPlaces: makeTagged("match:and", [
      makeTagged("match:gte", -100),
      makeTagged("match:lte", 100),
    ]),
  },
])`
```

### Security Considerations

Unlike `q`, `qp` does not lazily postpone rendering the expression into
Justin. `q` can do this easily because it is inside the `'ses'`
assert.js module and can use the rights amplification available only
there. `qp` depends on `'@endo/marshal'` which is several levels up from
`'ses'`. Rather than expose these rights amplification powers (or
several other kludges that failed), I just made `qp` non-lazy. Thus
there are no security implications.

### Scaling Considerations

Because `qp` is not lazy, simply constructing an error with `Fail` or
`makeError(X...)` will pay all the cost of rendering to Justin, whether
or not that error is ever used.

### Documentation Considerations

Because Justin is a subset of HardenedJS, the Justin expressions
produced by `qp` can be used in documentation if needed. Though see
Compatibility Considerations below.

### Testing Considerations

- [ ] Only minimal tests written for `qp`. We should also write a test
that loops through all the `jsonJustinPairs`, just as other Justin tests
do.

### Compatibility Considerations

Using Justin with symbols exposes in the rendered string how Justin
currently represents passable symbols. That changes in #2793. Whichever
of these gets merged first, the other will have to reconcile merge
conflicts. And any saved Justin strings containing that old Justin
representation will need to be updated or marked stale.

### Upgrade Considerations

Other than the Compatibility Considerations above, none.

- [x] Update `NEWS.md` for user-facing changes.