[tool] Add a package-level pre-publish hook

[stuartmorgan-g]

Adds the ability for a package to specify a script that should be run before publishing. To minimize the chance of such a script breaking things only in the post-submit release step, if the script is present it will also be run during publish-check.

These should be used with caution since they can cause the published artifacts to be different from that is checked in, but in the intended use case of extension builds this risk is far preferable to the risks associated with checking in binaries that were built on local, ad-hoc basis. (Longer term, we may need an alternate solution however, as generating artifacts in CI can have its own supply chain validation issues.)

Also does some minor refactoring to custom test script code to make it follow the same pattern as this new code.

Fixes flutter/flutter#150210

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I linked to at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style, or this PR is exempt from CHANGELOG changes.
• 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.
• All existing and new tests are passing.

[bparrishMines]

LGTM

Code looks good to me, but I do have some thoughts on the use case. It looks like this is mainly being done to build binaries/artifacts before publishing. Could it be possible that building could be needed outside of publishing (as in for testing)? Should the script be called something like generate.dart instead so that other commands could potentially make use of it?

[stuartmorgan-g]

Could it be possible that building could be needed outside of publishing (as in for testing)?

In general, I think special script entry points should be clearly named, and then if we have code we want to run from multiple entry points the best option is to factor that out into code that the different entry point files can call into.

[auto-submit]

auto label is removed for flutter/packages/7156, due to - The status or check suite Mac_arm64 ios_platform_tests_shard_3 master has failed. Please fix the issues identified (or deflake) before re-applying this label.

• The status or check suite Mac_arm64 ios_platform_tests_shard_4 master has failed. Please fix the issues identified (or deflake) before re-applying this label.

[auto-submit]

auto label is removed for flutter/packages/7156, due to - The status or check suite Mac_arm64 ios_platform_tests_shard_3 master has failed. Please fix the issues identified (or deflake) before re-applying this label.