Design changes to known/allowed culture list and cache

[Eilon]

1. Have default allowed culture list be empty
   • Make setting the default culture mandatory when using AddLocalization
   • If you want to support a specific set of cultures, pass in a default culture and also a set of allowed cultures
2. The loc middleware upon seeing the request’s desired cultures will compare it against the list of SupportedXyz cultures for an exact match (case insensitive). If it’s not any of those, fall back to the default culture
3. Rename AllowedXyz to SupportedXyz for lists of cultures
4. Keep CultureInfoCache and use it for all CultureInfo retrieval, including registering “unknown” cultures. The list of Known Cultures will go away.

[omuleanu]

@Eilon we should have the option to make the application use the browser language (Accept-Language header) without having to specify every single possible culture in RequestLocalizationOptions.SupportedCultures

equivalent to:
<globalization culture="auto" uiCulture="auto"/>
in web.config

[Eilon]

@omuleanu I believe there were some concerns around allowing completely arbitrary cultures that browsers send, which would potentially cause internal culture caches to potentially grow infinitely, causing memory issues. On OSes such as Windows 10, there is an infinite number of valid cultures, and ASP.NET Core Localization has to cache them (because creating cultures is a bit expensive), so if browsers send en-US-1, en-US-2, ..., en-US-9999 then ASP.NET's culture cache would grow and take up all memory.

Our belief is that sites only support a relatively small set of cultures (at most a few dozen, and that's extremely rare), so listing them all is reasonable.

If a site wishes to support completely arbitrary cultures (i.e. allow anything a browser sends), then they will have to use some other middleware.

@ryanbrandenburg @DamianEdwards was this the exact reason? Or was there something else?