[UI] Non-binding placeholder text and "quick option" suggestions for form fields

This is a follow-up to #704, which was closed without a resolution. Re-raising it here with an additional related proposal (quick-option suggestions), since both address the same underlying gap: shape authors currently have no way to hint at an example or likely value for an empty field without that value being enforced, derived, or committed to a closed enumeration.

1. shui:placeholder — inline placeholder text

Request for a shui:placeholder that specifies a string value to display when a property lacks a current value.

• Strictly not an actual enforced, derived, or default value for that property — unlike sh:defaultValue or sh:hasValue.
• Likely only meaningful for PropertyShapes without sh:node, or with sh:nodeKind of IRI or a literal (i.e. single-value, text-like widgets such as shui:TextFieldEditor / shui:IRIEditor), rather than blank-node or nested-form fields.
• Maps cleanly to the HTML <input placeholder="example@example.com"> attribute, so it's trivial for shui:TextFieldEditor/shui:IRIEditor implementations to support.

2. Quick-option / suggestion values below the field

A lighter-weight companion to shui:searchQuery and, more distantly, dash:propertySuggestionGenerator: a static (or simply-derived) list of candidate values a renderer can display as clickable "quick option" chips beneath a field, letting the user fill the field in one click.

• Not a validity constraint — unlike sh:in / shui:EnumSelectEditor, which restrict the property to only the listed values, these are just suggestions; the user remains free to enter something else.
• No live query/search step required, unlike shui:searchQuery, which is designed for dynamic, typed-input-driven lookups. This is closer to a small, precomputed candidate set.
• Exact term is open — shui:suggestedValues, shui:quickOptions, or similar — happy to defer to WG naming conventions.

Where this might fit

The spec currently has an open placeholder section, "Enumerations, Select Lists, and Autocomplete", marked TODO, which explicitly calls out the need to "distinguish static enumerations from dynamic lookups." Both proposals above seem like natural additions to that section and to the Built-in Widgets list (as new widget-score criteria for shui:TextFieldEditor etc.), rather than new top-level sections.

Happy to help draft the syntax rules / scoring criteria if there's WG interest.

Start with the open “Enumerations, Select Lists, and Autocomplete” TODO in the SHACL UI spec, then review the Built-in Widgets section and existing shui:searchQuery, sh:defaultValue, sh:hasValue, and sh:in definitions. Done would require agreed syntax for non-binding placeholders and suggestions, plus corresponding widget criteria documented in those sections.