CLDR-15830 Use getNameFromTypenumCode instead of getNameFromTypestrCode

[btangmu]

-Switch almost all calls to use integer instead of string

-TODO comments for 3 exceptions where getting integer is challenging

-Fix off-by-one bug in CLDRFile.typeNameToCode

-New unit test for CLDRFile.typeNameToCode

-Move some calls to nameGetter() out of loops, re-use

CLDR-15830

• This PR completes the ticket.

ALLOW_MANY_COMMITS=true

[btangmu]

bug fix, off-by-one, SUBDIVISION_NAME == LIMIT_TYPES == 15

[btangmu]

Still to do:

1. Fix the 3 new TODO items to use getNameFromTypenumCode instead of getNameFromTypestrCode, then remove getNameFromTypestrCode
2. Change int to Enum for LANGUAGE_NAME, etc.
3. Possibly move that Enum and related code from CLDRFile to NameGetter
4. Rename some methods like getNameFromBCP47 to reflect the possibility that the identifiers in question may be "extensions" of BCP47, not strictly BCP47; this question needs clarification
5. Further refactor NameGetter to avoid methods with too many parameters, consider Builder pattern as Steven suggested, see https://www.baeldung.com/java-fluent-interface-vs-builder-pattern
6. Steven suggested possibly following naming conventions of ICU4J https://unicode-org.github.io/icu-docs/apidoc/released/icu4j/com/ibm/icu/text/LocaleDisplayNames.html
7. Avoid boolean params as in getNameFromBCP47Bool(localeOrTZID, false), use enums instead
8. Per the ticket description, go beyond refactoring -- implement better tracking (“where found”) so that GlossonymConstructor.valueIsBogus isn't over-relied on to recognize inheritence of codes, etc., from code-fallback, etc.

[srl295]

nice use of enums