Create simple mechanism to trigger codegeneration

[RickWinter]

Something to the likes of
cargo generate

[heaths]

For context, I don't think this should be in a build.rs file. Even if it's conditionally triggered on an env var or something, anyone using our crates will require extra build time to compile a build.rs file to an executable, run it, and then generate source that likely wasn't even regenerated. You can add files and env vars to the watch list, but this still require extra build time and Rust is slow enough to build already.

TypeSpecs shouldn't be changing often enough to warrant this, IMO. But I could see providing a cargo xtask task or similar, or even just a build script under eng/scripts that not only takes care of a platform-agnostic and non-PATH-specific mechanism to executable tsp-client (e.g., #1966 at the time of this writing is Windows- and PATH-specific), but could even take care of acquisition of tsp-client if easy enough to do in a platform-agnostic way.

[heaths]

To note, this should be responsible for running cargo fmt. See #1981 for context.

[heaths]

While it would increase initial build time slightly, it wouldn't affect downstream users if we emitted the cargo::rerun-if-env-changed=AZURE_GENERATE_CODE or something like that. See docs for more info.

Still, this feels like driving a thumbtack with a sledgehammer. It's useful for us, yes...sometimes...but never for end users. And even if Azure SDK devs are building multiple crates - like the entire workspace by default - everything gets regenerated unless we use crate-specific env vars. That is, this has virulent behavior.

Instead, I think it's best if we just have a script under eng/scripts that regenerates when needed. It's not like services are often updating enough to make this transparent, and we're in a different ecosystem unlike most of our other languages that include this as part of their build command because, like .NET for example, the downstream devs don't get the .csproj - just the produced binary.