Refactor "gen-l10n" command to use same code path when "l10n.yaml" is present or not present

[thkim1011]

I think this is a long needed change to the gen-l10n command. Essentially, the arguments to flutter gen-l10n can be provided by two different methods: via command line arguments or via the l10n.yaml file. The existence of a l10n.yaml file causes the latter approach to take precedence.

However, currently, there's several differences in how the two approaches are handled, and most of the default arguments are all over the place, causing unexpected issues such as #120457 or #120023.

This PR refactors the command so that

• LocalizationOptions are more consistent with the actual argument names/yaml options.
• All default values are determined in LocalizationOptions's constructor (or in argParser.addOption(...) in the case a boolean value needs to be explicitly true).
• New parseLocalizationsOptionsFromCommand function to parse arguments.
• Parse LocalizationOptions at the beginning of runCommand() and pass it to generateLocalizations.

Fixes #120023.

[christopherfujino]

Why are we no longer catching L10nException? Does this get caught somewhere else?

[thkim1011]

Yep, this already happens in generateLocalizations.

[christopherfujino]

can we lift this hack to the callsite of parseLocalizationsOptionsFromYAML and make arbDir a required field here (or just restore the original behavior where this fallback is in the arg parser)? Generally, introducing a globals.dart import to a new library should be avoided. Eventually we want to ban all use of globals getters, and require them all to be direct injected from the top down: #47161

[thkim1011]

What are your thoughts on passing down globals.fs into parseLocalizationsOptionsFromYAML and parseLocalizationsOptionsFromCommand and call fileSystem.path.join('lib', 'l10n') at those two locations? I think parseLocalizationsOptionsFromYAML are used in several different locations, and I'd prefer to consolidate the default values if possible.

[christopherfujino]

To me hiding this fallback behavior deep in a helper function makes the overall behavior of whatever top level command that calls it more difficult to reason about, rather than lifting the fallback as high as possible and making the rest of the references to the value final.

[christopherfujino]

LGTM

[auto-submit]

auto label is removed for flutter/flutter, pr: 125429, due to - The status or check suite Mac channels_integration_test has failed. Please fix the issues identified (or deflake) before re-applying this label.

• The status or check suite Mac native_ui_tests_macos has failed. Please fix the issues identified (or deflake) before re-applying this label.
• The status or check suite Mac tool_tests_general has failed. Please fix the issues identified (or deflake) before re-applying this label.
• The status or check suite Mac tool_integration_tests_1_4 has failed. Please fix the issues identified (or deflake) before re-applying this label.
• The status or check suite Mac plugin_test_ios has failed. Please fix the issues identified (or deflake) before re-applying this label.
• The status or check suite Mac plugin_test has failed. Please fix the issues identified (or deflake) before re-applying this label.
• The status or check suite Mac plugin_dependencies_test has failed. Please fix the issues identified (or deflake) before re-applying this label.
• The status or check suite Mac dart_plugin_registry_test has failed. Please fix the issues identified (or deflake) before re-applying this label.
• The status or check suite Mac customer_testing has failed. Please fix the issues identified (or deflake) before re-applying this label.