Allow add_format() in flutter gen-l10n DateTime format

[Albert221]

This Pull Request extends the functionality of the flutter gen-l10n command (and its behavior during hot restart/reload) related to DateFormat type placeholders and their format. Until now, it was impossible to take advantage of intl's DateFormat.something().add_somethingElse(). The .add_x() part was impossible to achieve. This PR adds the ability to take advantage of these methods over DateFormat, by adding the add_ formats after the + character in the format in placeholder configuration. You can even have multiple added format parts if needed. All within a single placeholder.

Before the PR	After the PR
{ "bookingsPage_camo_dataLoaded": "CAMO data from {date} {time}.", "@bookingsPage_camo_dataLoaded": { "placeholders": { "date": { "type": "DateTime", "format": "yMMMd" }, "time": { "type": "DateTime", "format": "jm" } } }, }	{ "bookingsPage_camo_dataLoaded": "CAMO data from {date}.", "@bookingsPage_camo_dataLoaded": { "placeholders": { "date": { "type": "DateTime", "format": "yMMMd+jm" } } }, }

Resolves #155817.

Next steps

After this PR is merged, an update to i18n | Flutter > Messages with dates (source) shall be made to include a mention of this new addition.

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
• I signed the CLA.
• I listed at least one issue that this PR fixes in the description above.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• I followed the breaking change policy and added Data Driven Fixes where supported.
• All existing and new tests are passing.

[Albert221]

CC @andrewkolos, that's ready for Code Review now. The implementation turned out to be extremely simple. As for the tests, I added a case for the setup that already existed for the gen-l10n.

[andrewkolos]

Thanks for the PR!

The approach looks good, and the code is delightfully simple. That being said, I think we should have test(s) that define the behavior around odd formats that could be made with this new syntax. For example, consider the format "yMd+jms+", which has a dangling +. What should the user see here? An error message? Would the last + be implicitly removed?

[bkonyi]

@Albert221 do you have plans to pick this back up?

[Albert221]

@bkonyi I plan to return back to this PR in a week or two, yes; unless you'd like to add the remaining things, then tell me and fell free :)

[Albert221]

@andrewkolos tests added! Code ready for re-review. I'm not sure what's the issue with some of the unrelated tests failing though, should I merge from upstream everytime I get that?

EDIT: Merged latest main into PR. Now Windows tool_integration_tests_2_9 passes but Mac_x64 framework_tests_misc does not. I don't think that's because of my changes