Let a registered preview target set its own expiry, and remove it

Problem/Motivation

A frontend that registers its own preview target can't say how long the target lasts, or remove it when it stops. A short-lived frontend, such as a tunnel or a branch build, leaves its target behind. The target stays in the Frontend picker for a day, then sits in the Inactive targets group until cron deletes it 30 days later.

Proposed resolution

• A PATCH to /api/consumer-node-preview/targets takes an optional expires_in on the target, in seconds. The target stores an expires time: the request time plus expires_in, capped at the Delete after setting.
• Once that time comes, the target leaves the Frontend picker, and a preview doesn't get a token for it. Cron then deletes it.
• Each PATCH sets a new time. A PATCH without expires_in leaves the target with none, under the site's own limits as before.
• A DELETE with {"target": {"label": "..."}} removes the target with that label, with the same access checks as PATCH. A label that no target has changes nothing, so a frontend can repeat the request when it shuts down.
• consumer_node_preview_update_10001() adds the expires column to a 1.0.0-beta1 site. Drupal won't change a field's columns while it holds data, which a site with registered targets does. So the update adds the column in place and records the new schema, and the targets stay as they were.

Remaining tasks

• Review the merge request.

User interface changes

The Registered targets help text on the Preview tab says a frontend can give its target an earlier expiry of its own.

API changes

The targets endpoint accepts expires_in on PATCH, and a new DELETE method. Every answer lists each target's expires. PreviewTargetsProviderInterface::getTargets() and getTargetByKey() return expires too.

Data model changes

The preview_targets field gains an expires property and column, with an update for existing sites.