Fix TypeError in cylc message mutation form

[MetRonnie]

Closes #2410

Bug

Results in nothing happening and this error:

TypeError: Cannot read properties of null (reading 'length')

Check List

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Tests are included (or explain why tests are not needed).
• Changelog entry not included as minor
• Docs not needed

[MetRonnie]

Mixins did not make it fun to figure out where modelValue is coming from, but it's here:

cylc-ui/src/components/graphqlFormGenerator/mixins.js

Lines 23 to 37 in cb0032a

	props: {
	// the GraphQL type this input represents
	gqlType: {
	type: Object,
	required: true
	},
	// array of all GraphQL types in the schema
	types: {
	type: Array,
	default: () => []
	},
	// the value (v-model is actually syntactic sugar for this)
	modelValue: {
	required: true
	}

We shouldn't be mutating the prop, instead we should be using the model getter/setter

[oliver-sanders]

Code looks good, but got some odd behaviour:

[MetRonnie]

That's expected, the format of messages is [[severity, message], ...] (see the help text), which admittedly is a little awkward, but would need a schema change to address

[oliver-sanders]

Ach right, that makes sense.

Cool, truth be told, we don't really want to expose the cylc message API via the GUI (accidental side-effect of aotf), so a clunky interface is no biggie (we may want to consider redacting the message command from aotf).

This is a genuine fix to the form generator fixing a bug which could occur in any other mutation, so well worth doing irrespective.

[oliver-sanders]

@wxtim, could you give this a quick once-over.

This PR is basically a composition API refactor (you can actually test the bugfix part with model || [] in the original code), should be no functionality change, other than the bugfix of course.

Don't worry about the confusing message command form (see above).

[MetRonnie]

An advantage of the composition API is (since Vue 3.5) it is much easier to define v-models on components. This makes it easier to avoid mutating props, which is flagged up in newer versions of eslint-plugin-vue (#2142 (though I don't think the plugin can tell when a prop is added by a mixin))

[wxtim]

This feels like it ought to be in a general utilities module?