Bundletool performance, Bundletool as an Installer

We use `apple.experimental.tree_artifact_outputs`, and for our apps it takes a consistent 8-9s to run `bundletool_experimental.py` to construct the `.app`. This is something I'd like to optimize for local builds, to speed up the edit-compile-run cycle.

Have there been any discussions about future work for the bundletool, specifically the experimental (tree) version. For what it's worth, I notice that `experimental.tree_artifact_outputs` isn't documented.

Secondly, what do people think about the option of making rules_apple not run bundletool, instead have some `{sh,py}_binary` rule would produce an "installer" – which wraps bundletool, that we can run after the `bazel build`. For local development, after each `bazel build` the `.app` or `.xctest` bundles need to be copied to `DerivedData`, which adds a little more time. This could be faster if we skip the middle man and instead construct the `.app` where we want it (`DerivedData`).

Start by profiling bundletool_experimental.py for builds using apple.experimental.tree_artifact_outputs, then review the undocumented experimental.tree_artifact_outputs option. Compare the current bundle placement and copying into DerivedData with the proposed installer approach. Done would require a decided scope and an agreed design for improving local build performance.

Written by the indexing model from the issue text.