Make LocaleDataDict Generic

[DenverCoder1]

Type annotation improvements:

• Made LocaleDataDict use TypeVars so that the key and value types can be annotated for each instance
• Fix type issues related to LocaleDataDict
• Added repr method to LocaleDataDict

Other changes moved to #966

[codecov]

Codecov Report

❌ Patch coverage is 98.03922% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 90.90%. Comparing base (373a52f) to head (96a7a52).
⚠️ Report is 152 commits behind head on master.

Files with missing lines	Patch %	Lines
babel/localedata.py	94.73%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #961      +/-   ##
==========================================
- Coverage   90.91%   90.90%   -0.02%     
==========================================
  Files          25       25              
  Lines        4350     4353       +3     
==========================================
+ Hits         3955     3957       +2     
- Misses        395      396       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[akx]

2. Changed Locale.parse to always return a Locale (this fixes type issues in multiple places where the return type is assumed to not be None)

That's a great change – I don't think it messes up any valid downstream workflows. However seeing as that retval was added here 8b7c5e1 in a commit that talks about likely subtag resolving, could you make sure that it doesn't affect that functionality? I think we might need to do if identifier is None: raise IdentifierNone() and catch it where there currently are other if locale is not Nones...

[DenverCoder1]

2. Changed Locale.parse to always return a Locale (this fixes type issues in multiple places where the return type is assumed to not be None)

That's a great change – I don't think it messes up any valid downstream workflows. However seeing as that retval was added here 8b7c5e1 in a commit that talks about likely subtag resolving, could you make sure that it doesn't affect that functionality? I think we might need to do if identifier is None: raise IdentifierNone() and catch it where there currently are other if locale is not Nones...

As far as I can tell, there aren't any locations in the lib that expect the return type of Locale.parse to be anything other than Locale. I don't see any places where parse is used and then the type is checked to be None or not be None.

The places that check for locale being None are ones where a different method is used.

It could raise a different exception from the standard ValueError, but it doesn't seem that it would need to be caught internally.

[akx]

I'm a little wary about the LocaleDataDict changes... The numbers changes look alright though, can you break them out into a separate PR?