BL-15436 another fix for chinese name handling

[nabalone]

This change is 

[github-actions]

Palaso Tests

     4 files  ±0       4 suites  ±0   10m 9s ⏱️ -58s
 5 070 tests ±0   4 836 ✅ +1  234 💤 ±0  0 ❌  - 1 
16 525 runs  ±0  15 804 ✅ +1  721 💤 ±0  0 ❌  - 1 

Results for commit 1711603. ± Comparison against base commit a8fcda9.

♻️ This comment has been updated with latest results.

[imnasnainaec]

@imnasnainaec reviewed all commit messages.
Reviewable status: 0 of 2 files reviewed, 2 unresolved discussions

---

SIL.WritingSystems/IetfLanguageTag.cs line 1318 at r1 (raw file):

				if (uiLanguageCode == "en")
					return kSimplifiedChineseNameInEnglish;
				return kSimplifiedChineseAutonym;

Using kSimplifiedChineseAutonym (resp. kTraditionalChineseAutonym) for all uiLanguageCode != "en" is a decision that removes the possibility of other ui languages having their own translation. The changelog and/or these method summaries and/or the above comments should probably reflect that decision.

---

SIL.WritingSystems/IetfLanguageTag.cs line 1604 at r1 (raw file):

				case "中文(台湾)":
				case "中文（台湾）":
					return kTraditionalChineseAutonym;

There are two function which call on FixBotchedNativeName and this pr entirely handles the (generalCode == ChineseSimplifiedTag) and (generalCode == ChineseTraditionalTag) cases before that call. So it's reasonable to remove the various Chinese cases here. However, there are a few reasons to consider leaving them:

1. They appear to cover known botches, so leaving them allows for a more robust function that can be used if the calling functions are later refactored.

2. They help cover odd language code situations, such as zh-Hans-CN, which would give generalCode = zh (rather than zh-CN).

3. For consistency with the درى case that's still here, even though (generalCode == "prs") is handled rather than calling FixBotchedNativeName.