BUG: Fix ctkLanguageComboBox normalizing default language and selection

[jcfr]

Discovered during the resolution of issues in ctkLanguageComboBoxTest, this commit addresses a bug in the normalization and selection of the default language in ctkLanguageComboBox.

It introduces the function normalizeLocaleCode to ensure that the default locale code is set to its normalized value if valid.

Furthermore, the updateLanguageItems() function is updated to select the default locale code if the user has not already made a selection.

[lassoan]

Furthermore, the updateLanguageItems() function is updated to select the default locale code if the user has not already made a selection.

Could this have the unintended side effect that if the widget is used in the application settings then it writes in some language automatically (as if the user actively selected it)? That would not be nice, because we could not distinguish if the user selected English explicitly (in this case we should use English) or the user simply did not select a language (in this case we may decide in the future to use for example the operating system's language).

[jcfr]

Could this have the unintended side effect that if the widget is used in the application settings then it writes in some language automatically (as if the user actively selected it)?

It seems the language combobox is trying to be both a manager and language selector, moving forward we should probably look into introducing an object for dealing with the scanning of a directory, dealing with default vs explicitly selected ...

This should probably be done in future improvements.

With this fix, the test now pass and the behavior reported in SoniaPujolLab/SlicerLanguagePacks#57 is fixed.