[mustache_template] Fix auto-generated specification tests, run with `dart test` (#11056)

This PR reorganizes the tests in mustache_template such that CI can run them, per the second option proposed in flutter/flutter#174721. The changes include a script to pull mustache specifications from the mustache repository and note the time/date and commit hash of that action, along with documentation of the above and the new test structure laid out below.

The former `all.dart` (which called three `main` functions in three test files) is now `mustache_test.dart`, and the former `mustache_test.dart` (which contained handwritten tests) is now `feature_test.dart`. The `mustache_specs.dart` file is now solely responsible for generating the tests in `mustache_test.dart` from the mustache specs, and no longer has a `main` of its own.

As this implementation doesn't support two of the optional mustache specs (inheritance and dynamic names, which were added to the mustache repo in the early 2020s, while the original mustache_template package was written in the mid-2010s), this PR also adds an UNSUPPORTED_SPECS constant in `mustache_test.dart` that skips generation of tests from those spec files.

(Separately, I'm working on an implementation of the inheritance spec, so it seemed better to pull all the specification files and selectively disable the unsupported ones.)

## Pre-Review Checklist

### Exemptions
- Version change exemption: PR affects tests only.
- CHANGELOG exemption: PR affects tests only.

**Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.

[^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.