Validate l10n ID is non-empty to prevent crash on empty string ID

[imnasnainaec]

Closes #104

Passing a null, empty, or whitespace string as the id argument to GetString/GetDynamicString produced a malformed or zero-length .xlf file that crashed the application on the next launch.

The fix is in XliffTransUnitUpdater.Update: a guard (mirroring the existing LangId check) now exits early when id is null/empty/whitespace, preventing the corrupt entry from ever being written. The public API methods (GetDynamicString, GetDynamicStringOrEnglish, GetString) return the English fallback text when called with a blank ID rather than attempting a cache lookup or write, so this is a non-breaking fix.

Note on StrictInitializationMode: the early-return in GetString bypasses the StrictInitializationMode check inside GetStringFromAnyLocalizationManager. An app with StrictInitializationMode = true and no managers loaded will now get English fallback text instead of InvalidOperationException when a blank ID is passed. This seems like the right behavior — throwing about missing managers when the real problem is a blank ID would be the wrong signal — but it is an observable change in that scenario.

---

This change is

Devin review: https://app.devin.ai/review/sillsdev/l10nsharp/pull/146

[github-actions]

Test Results

    7 files  ±  0  124 suites  +20   37s ⏱️ +12s
185 tests +15  180 ✔️ +15    5 💤 ±0  0 ❌ ±0 
706 runs  +60  691 ✔️ +60  15 💤 ±0  0 ❌ ±0 

Results for commit c7fe0a2. ± Comparison against base commit 69c056e.

♻️ This comment has been updated with latest results.

[andrew-polk]

If we're truly treating this as a breaking change, it needs semver:major in the commit message.

Initially, I was going to approve the general idea, but I'm getting more and more hesitant.
I wouldn't be at all surprised if Bloom (or some other program) is accidentally making use of the fallback behavior and sending null or empty sometimes.

Can we solve instead solve the underlying problem while maintaining the immediate behavior of falling back to english?

I'm not sure what can cause the corrupt file, but can we just exit early, returning the English or ID instead of throwing, for example?

@andrew-polk reviewed 4 files and all commit messages, and made 2 comments.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on imnasnainaec).

---

CHANGELOG.md line 35 at r1 (raw file):

- [L10NSharp.Windows.Forms] Removed emailForSubmissions parameter (8th parameter) from LocalizationManagerWinforms.Create. Since the localization dialog was jettisoned, it no longer makes sense to store this information on the localization manager.
- [L10NSharp] Replaced the .NET 8.0 target with .NET Standard 2.0 for broader compatibility.
- [L10NSharp] BREAKING CHANGE: `LocalizationManager.GetString`, `GetDynamicString`, and `GetDynamicStringOrEnglish` now throw `ArgumentException` when called with a null or empty string ID. Previously, empty IDs were silently accepted and could produce a malformed XLIFF file that crashed on next launch.

This says null or empty, but the actual check is whitespace.

[imnasnainaec]

Went for the English/empty fallback instead of the throw.

@imnasnainaec made 2 comments.
Reviewable status: 0 of 4 files reviewed, 1 unresolved discussion (waiting on andrew-polk).

---

CHANGELOG.md line 35 at r1 (raw file):

Previously, andrew-polk wrote…

This says null or empty, but the actual check is whitespace.

Done.

[andrew-polk]

@andrew-polk reviewed 4 files and all commit messages, and resolved 1 discussion.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on imnasnainaec).