Revisit API and implementation of `target_exe`

[ranweiler]

Right now, for any given task, the following are true:

• The target_exe parameter (TaskDetails.target_exe) must be a setup blob container-relative virtual path
• The target_exe parameter cannot contain any Expand placeholders (see Expand fails to work recursively with some combinations #2387)

Server-side, when generating a TaskUnitConfig', we hard-prepend setup/ to TaskUnitConfig.target_exe (which is what the task executor on the VM eventually receives). As a result, the implementations of the tasks assume that target_exe is always directly addressable relative to the current working directory of the executor, which contains the setup dir under the concrete name setup.

From the perspective of the onefuzz-task executor, if we invoked tree ., we'd see something like:

.
├── crashes_1
├── inputs_2
├── readonly_inputs_3
├── setup
│   └── fuzzer.exe
└── tmp.5cj9Wh2pzl

...with the specifics depending on the task being executed. However, we will always have a directory ./setup, which will always contain the task target_exe. The server-side tables will have TaskDetails.target_exe == fuzzer.exe, but the task config JSON on the VM (via the server-generated TaskUnitConfig) will have TaskUnitConfig.target_exe == setup/fuzzer.exe. Similarly, for crash repro, we generate a GDB script (here or here) that does a similar hardcoding, directly from the TaskDetails.

This all has a few quirks and/or problems:

• target_exe is special and different from other .._exe config parameters, which must use an expansion placeholder variable to relativize to {tools_dir} or {setup_dir}. In contrast, target_exe cannot be relativized, either conceptually or in implementation. The other .._exe params can be any path (including absolute paths)
• At least in templates, some special conditions apply to the relationship between target_exe and setup
• From the user perspective, target_exe is always a virtual blob path (relative to the setup dir), but other .._exe params are path strings with placeholders that semi-implicitly specify any source blob storage container "inline" (via use of {setup_dir}, {tools_dir}). They may also allow hardcoded paths.
• The server-side, hardcoded prepending of target_exe is distributed, inflexible, and brittle. Task implementations silently depend on the preconditions about target_exe's relative path construction and the relationship of those relative paths to the setup directory
• Not all expansion placeholders make sense to enable in target_exe (or similar). Enabling {setup_dir} expansion would currently motivate enabling as much expansion as makes sense in some server-side contexts, but this will almost never make sense. Furthermore, if it does make sense, it would ideally be managed by a special repro executor at VM runtime (not done server-side). There is no server-side precedent for pre-expanding placeholder variables (nor does it make semantic sense).

Possible approaches (some of which can be combined):

• Require callers/clients to prepend {setup_dir} to target_exe, and require users of {target_exe} to expand it.
• For .._exe params, require outlined naming of the source container along with .._exe params, and do NOT require (or allow) a placeholder var in params. In other words, define all such params to either explicitly be blob-relative virtual paths (with a named container root), and maybe allow bare absolute paths.
• Replace all server-side script generation with on-VM code (e.g. for repro).
• Replace all hardcoding with clear, documented demands on .._exe consumers for runtime interpretation (even if target_exe remains special).

AB#36047