UI: remove references to comma separation for string array edit types

[hellobontempo]

Models that build from openApi use the description key as helpText which renders as a tooltip beside the label. These descriptions are written for CLI users and so the tooltips are misleading in the UI for inputs with editType: stringArray. The tooltip will say to input comma separated values, but the UI doesn't actually accept this for that specific input type.

This PR:

1. Adds a new description block to the DisplayAttributes struct that generates an attrs open api schema
2. globally adds Add one item per row as subtext to all <StringList> inputs rendered by the <FormField> component (which all models that leverage openAPI use)
3. adds a warning to the <StringList> input itself if a comma exists and reminding to input separate values individually

Fixes #19451
Fixes #10346

demo of fix and validations

---

k8 role

---

Abandoned idea: sanitizing the input and stripping out the comma

The CLI can accept an array of strings or a comma separated string for these parameters. However, these type values map to type stringArray which are only treated as an array in the UI.

# sample schema from the backend that maps to stringArray in the UI
{
    "type": "array", 
    "description": "A comma-separated list of names. At least one must exist in the Common Name. Supports globbing.",
    "items": {
        "type": "string" 
    }
}

Technically a ["string, with comma"] inside an array is allowed, though probably unlikely. We also don't have an existing pattern of changing user-inputted data under the hood. Instead we display warnings to confirm any unexpected characters/values are intentional (i.e. extra spaces) instead of stripping them out in the serializer and changing the data unbeknownst to the user.

[Monkeychip]

I am not sure how often and for what cases we would use a semicolon. This comes from my experience making language changes and Ivana correcting them :) . From what I can remember, she avoided them and stuck with a period. (Note: trying to search for text with semicolons is a challenge given how much we use them for all other things...)

[hellobontempo]

Since they're related independent clauses a semicolon felt appropriate here, the super short sentences seemed really choppy. But I can defer to design!

I also thought about removing the second part all together, since it felt like it was only there so add the part about adding one per row

[Monkeychip]

same comment here re: ;

[zofskeez]

LGTM 🚀

[hellobontempo]

Removed here since it now renders above each input.

[hashishaw]

Great work! Just one small nit, otherwise LGTM

[hashishaw]

Could we not add description above on line 19? Would make this a bit clearer. If we needed to rename it to something so a falsey value doesn't override the previous definition of description you could rename it like { ..., description: openApiDescription } = prop[...]

[hellobontempo]

Great idea!

[hellobontempo]

Opened #20231 without ui/ prefix to run backend tests