Make WritingSystemSetupDialog localizable

[imnasnainaec]

Summary

• Wire up L10NSharpExtender in WritingSystemSetupDialog.InitializeComponent(), matching the pattern used by all sibling dialogs in the project (LocalizationManagerId = Palaso)
• Set localizing IDs on _closeButton, _openGlobal, _openDirectory, _openLabel, and the form title
• Replace 4 hardcoded strings in code-behind (InputSystemsError, folder-browser description, two dlg.Text assignments) with LocalizationManager.GetString() calls
• Side-effect: initializing components activates the pre-existing DisposeRepository cleanup in Dispose, fixing a resource leak when the all-users child dialog is closed

Test plan

• UITests.WritingSystemSetupDialog_Construct_DoesNotThrow (marked [Explicit] — requires a running L10NSharp environment; run manually)
• Verify localized strings appear correctly in the dialog at runtime with a non-English L10N pack

Fixes #1337

Devin review: https://app.devin.ai/review/sillsdev/libpalaso/pull/1523

---

This change is 

[github-actions]

Palaso Tests

     4 files  ±0       4 suites  ±0   10m 39s ⏱️ - 1m 5s
 5 104 tests +1   4 870 ✅ ±0  234 💤 +1  0 ❌ ±0 
16 624 runs  +3  15 900 ✅ ±0  724 💤 +3  0 ❌ ±0 

Results for commit fdc054a. ± Comparison against base commit fad75f9.

♻️ This comment has been updated with latest results.

[imnasnainaec]

Claude response to Devin flags

1. L10NSharpExtender may override custom dialog titles on language change (WritingSystemSetupDialog.cs:122)

Valid concern: _openDirectory_Click and _openGlobal_Click set context-specific titles on child WritingSystemSetupDialog instances after construction. Because those instances now have an active L10NSharpExtender registered on this.Text, a runtime language-change event would reset the title back to the generic "Writing Systems" string.

Not actioning: this is the same tradeoff accepted by every sibling dialog in the project that already uses L10NSharpExtender. The scenario requires the user to change the app language while one of these uncommon, non-modal child dialogs is open — effectively unreachable in practice.

---

2. Adding components container now activates previously dead DisposeRepository code (WritingSystemSetupDialog.Designer.cs:39)

Finding is correct: the DisposeRepository logic sits inside if (disposing && (components != null)) in the pre-existing Dispose. Before this PR components was never assigned, so the block was dead code and dlg.DisposeRepository = true (set in _openGlobal_Click) had no effect — the GlobalWritingSystemRepository was silently leaked. Our this.components = new Container() line unblocks it.

Net effect is positive: the original developer clearly intended DisposeRepository to work (they wrote the property and set the flag). The repository is a fresh instance exclusively owned by that child dialog, so no caller can be relying on it surviving past the dialog's close. No action needed beyond noting this as an incidental bug fix.