[stress testing] Improve UX and sub-command usage of stress deploy scripts

See https://github.com/Azure/azure-sdk-for-net/pull/28320#discussion_r855675487

We should support more fine grained operations in dev usage of the stress scripts. Right now the script is written with the approach that its goal is to build and deploy a stress test to a cluster. However, it would be more useful to take an approach that focuses on automating various operations, like `deploy`, `build`, `buildImage`, `debug`. For example, we have some custom configuration around building of dockerfiles with external directories. In order to find the correct docker command you have to run the deploy script and copy the command from the log output. It would be better to just provide a sub-command or function like `buildImage` for this case.

Operations I can think of that we do today, some via the script and some manual:

- build (building the stress code, perhaps we should provide a common build script hook for this)
- buildImage (build the docker image)
- pushImage (push the docker image)
- run (run the docker image, this may be trickier or unnecessary since we haven't prioritized local flows given the ease of using k8s)
- debug (ssh into the container and/or attach a debugger to a container process? This is probably its own feature/issue)
- logs (tail the logs from an active stress test)
- show (show all active instances of this test)
- login
- template (helm template, validate stress config)
- deploy (normal operation of the script, login/build/push/helm install)
- deployAzure (deploy the bicep template, so that people can run locally against a static set of resources)
- uninstall/remove (remove test from cluster)
- dashboard (open dashboard links, etc.)
- docs (open docs)
- useLocalConfig/useRemoteConfig (switch helm repo under the hood for local addons dev)
- init (this could use the stress generator, or just create a boilerplate gitignore/dockerfile/templates/chart.yaml/etc.)

Start with the stress deploy scripts and the linked pull-request discussion, then trace the existing deploy flow and its logged Docker commands. Map which existing operations can become subcommands, including buildImage, logs, template, deploy, and uninstall/remove, and document a concrete scope before implementation. Done means the selected operations work independently without requiring the full deploy flow.

Written by the indexing model from the issue text.