Tooling to accept payload size changes

Currently in the angular/angular repo, when a change affects payload size for integration test app or AIO, an error is thrown on CI ([example CI failure](https://app.circleci.com/pipelines/github/angular/angular/43342/workflows/f4014ab1-aff3-4298-944b-f64c6a615e5f/jobs/1130977)):
```
FAIL: Commit undefined uncompressed main fell below expected size by 500 bytes or >1% (expected: 231381, actual: 230780).
If this is a desired change, please update the size limits in file '../.cache/bazel/_bazel_circleci/9ce5c2144ecf75d11717c0aa41e45a8d/execroot/angular/bazel-out/k8-fastbuild/bin/integration/cli-hello-world-lazy/test.sh.runfiles/angular/goldens/size-tracking/integration-payloads.json'.
```
We have a number of test apps (~10) for which we track payload size, thus it takes time to manually update everything. Also, minor payload size deltas between the main and a patch branches causes issues during the merge (when merge is requested to both main and patch branches), thus engineers end up creating a new PR and re-do all the manual updates to payload sizes once again.

It'd be great if we can have a tooling to update payload sizes, similar to what we have for tracking the symbols (via `yarn symbol-extractor:update`). That'd improve the quality of life for us, reduce CI reruns and save a bunch of time.

Also, I noticed that the payload size error for each app is present in [the CI output](https://app.circleci.com/pipelines/github/angular/angular/43342/workflows/f4014ab1-aff3-4298-944b-f64c6a615e5f/jobs/1130977) more than once. Do we run it multiple times for some reasons?

Start with the integration payload size-tracking golden file at integration-payloads.json and the existing yarn symbol-extractor:update entry point. Trace how CI compares each test app's payload and why the error appears more than once; done means a tooling command updates the tracked sizes for all affected apps without repeated manual edits.

Written by the indexing model from the issue text.