M6: keep field defaults in range; disable the item without a look

[marcoarnulfo]

Prepare a form: Use Current Properties as New Defaults for form fields

In Acrobat's Prepare Form you can right-click a field and choose Use Current Properties as New Defaults. Fields you add afterwards with the same tool get that field's properties, and fields that already exist stay as they are. This PR adds that item to the field's context menu in Prepare a form. It saves the right-clicked widget's Appearance tab (border and fill colour or none, line width and style, text colour, font) and its font size. Each field tool keeps its own defaults, so an image field and a button stay separate even though both are push buttons, and so do a date field and a text field. The defaults are saved with the settings and survive a restart. Check boxes, radio buttons and signatures take only the border and fill properties, and their /DA is left alone, so the ZapfDingbats mark is unaffected. A radio button that joins a group changes only its own widget. Choosing the item doesn't change the document, and a short notice confirms it. A tool with no saved defaults behaves as before. Edit::AddField gets an optional look, so the field and its look are added in a single Undo step. form_add_field takes the same appearance and font_size arguments as form_set_props, so the same result is reachable headless. Out of scope: the General and Options properties, which Acrobat may also carry over (I couldn't confirm which ones from its docs), and a "reset to built-in" command. Detected fields and fields added by document JavaScript keep ignoring the user's defaults. Happy to switch the per-tool split, or to have Image share Button's defaults. A default read from a field is clamped to what the Appearance tab accepts, so a file with /BS /W 15 can't leave a tool unable to make fields. The two new strings are in all 22 catalogs; a native speaker's glance at the non-Latin ones (Arabic, Bulgarian, Greek, Japanese, Kazakh, Russian, Telugu, Ukrainian, Chinese) would be welcome.

This is the second half of #2831. #2840 covers the first half (detected fields get no border or fill). The two PRs touch the same lines in two places: auto_detect_fields in js.rs, and the Edit::AddField constructor in #2840's engine test. Whichever PR lands second needs one more look: None, line, and I'll rebase promptly if #2840 merges first.

Validation:

• a_new_field_starts_with_the_saved_look, a_bad_saved_look_is_refused (forms): with the look ignored, they fail (the field gets the grey border and white fill, and an out-of-range width is accepted); they pass here
• current_properties_become_the_new_defaults_of_that_tool (ui-egui prepare), field_defaults_are_saved_with_the_settings, a_field_added_with_a_look_starts_with_it (automation): fail to compile on main (no look, no field_defaults), pass here
• the tests also fail when the look reaches every widget of a radio group (the group's first button turns red), and when defaults are keyed by field kind instead of by tool (the image field's defaults land under Button, so a new button would take the image field's border and a new image field gets none)
• out_of_range_properties_are_clamped_as_defaults: a field read with /BS /W 15 and /MK /BC [2 0 0] becomes a default of width 12 and red; without the clamp the next new field is refused
• cargo clippy -p pdfcraft-forms -p pdfcraft-engine -p pdfcraft-automation -p pdfcraft-ui-egui --all-targets -- -D warnings, cargo fmt --all -- --check, cargo xtask parity
• (macOS, Apple silicon)