If we re-run ConvertLanguageData on unrelated data, it will update the order and values of some other data -- this fixes inconsistencies with the XML outputs to match expectations. The biggest change was updating values in `language_script.tsv` to demote script variations to secondary when they really are not expected. Furthermore I added explicit annotations to `country_language_population.tsv` when the writing system for a country was a variant.

Scripts ran:

 mvn package -DskipTests=true
 java -jar tools/cldr-code/target/cldr-code.jar ConvertLanguageData
 java -jar tools/cldr-code/target/cldr-code.jar GenerateLikelySubtags

El Salvador has a number of local languages not yet included in CLDR -- this adds them.

See https://unicode-org.atlassian.net/browse/CLDR-11567 and https://translatorswithoutborders.org/language-data-for-el-salvador

Re-generated the xml with mvn package -DskipTests=true &&  java -jar tools/cldr-code/target/cldr-code.jar ConvertLanguageData &&  java -jar tools/cldr-code/target/cldr-code.jar GenerateLikelySubtags

`zlm` and `apd` are not languages of Togo -- there's a copy-paste error in the Likely Subtags overrides.

This fixes `apd` (Sudanese Arabic) by adding population counts -- I'll note that the ethnologue estimate is 48,000,000 million people, but the last Sudan census we have in the data shows only ~41 million people in the country -- so I want to be cautious. Since I had problems finding a reliable census I just duplicated the Standard Arabic value since likely most people in Sudan that use Arabic speak the Sudanese dialect but write Standard Arabic/ar.

For `zlm` -- Malay (individual language) that's even harder to get a thorough population value so I just fixed the override entry in GenerateLikelySubtags.