Add localization support for accelerators

[pljones]

When setting menu text (as an example), a localized string reference can be supplied. In IntelliJ, the FXML Text view shows the linked value when hovering the reference (as it does elsewhere).

The SceneBuilder UI appears to recognise the reference (the "%" prefix below):

However, there is no visual support for localized accelerators (which are often tied to the text - "Ctrl-S to Save") in the version of SceneBuilder built into IntelliJ 2023.3.4. Attempting to enter

                <MenuItem fx:id="jmiFileNewV3" onAction="#onFileNewV3" text="%miFileNewV3">
                    <accelerator>
                        <KeyCodeCombination alt="UP" code="%accFileNewV3" control="DOWN" meta="UP" shift="UP" shortcut="UP" />
                    </accelerator>
                </MenuItem>

will work at runtime -- but SceneBuilder fails.

Expected Behavior

It would be good if the FXML parser supported localization references for code in KeyCodeCombination.

Current Behavior

Currently, the code example above would cause an error message:

(It's not a particularly helpful error message, either: saying that the code attribute in the KeyCodeCombination element failed to parse would identify the cause, without having to edit the FXML to eliminate possible causes to identify the problem.)

Context

I had a working application with a set of localizations to apply. I edited the FXML by hand and ran the application and saw it was working as expected - the translations applied, including the accelerators.

However, the localization of the accelerators prevented me using SceneBuiler, as SceneBuilder appears unable to parse the FXML (and, as I'm guessing it's a DTD violation, it's essentially throwing away the whole document).

Minimal viable solution (not effective but an improvement) - upgrade the error message to show the failure reason.

Effective solution - add support for handling % translation references in SceneBuiler in the KeyCodeCombination element code attribute, even if (as with existing references) these are not resolved. (i.e. change the DTD to allow either a valid code or a syntactically valid translation reference).

Ideal solution - integrate a way to supply a localization resource to resolve references and add translation support. (But I guess that's a very big ask.)