Support building from Dockerfile.in templates in devcontainer.json using configurable preprocessing tool

[Mathiyarasy]

Fixes: #1223

Issue Description: Podman supports building from Dockerfile.in files by using the system cpp preprocessor to generate a valid Dockerfile before the build runs. Dev Containers do not currently support this workflow. The existing CLI reads the Dockerfile directly, identifies the final FROM stage, and then extends it with features. When the input is a Dockerfile.in that has not been preprocessed yet, the CLI may not see a resolved FROM instruction, which causes the build flow to fail.

Solution: The CLI now detects Dockerfile.in before parsing or build flow begins, and preprocesses it through a single configured tool invocation instead of an arbitrary list of shell commands. The preprocessor contract is now explicit: the user declares a tool, fixed args, and either an outputMode for direct-output tools like cpp, or a generatedDockerfile path for generator-style tools like cmake or meson. The CLI always owns the final preprocessed Dockerfile location and normalizes it to .devcontainer-preprocessed/Dockerfile, then continues the existing build flow using that file. This works in both the single-container path and the Docker Compose path.

• Tool availability still depends on the host:
• If the Dockerfile path does not end with .in, nothing changes.
• If it does end with .in, the CLI computes a fixed CLI-owned output path: .devcontainer-preprocessed/Dockerfile.
• It injects environment variables for the input path, final output path, workdir, and generated Dockerfile path.
• For direct-output tools, the CLI appends positional arguments based on outputMode:

  single-file => <input> <output>
  build-tree => <input> <output> <workdir>
  

• For generator-style tools, the CLI runs only the configured args and then looks for the declared generatedDockerfile.
• Verifies that the expected generated Dockerfile actually exists.
• If the tool generated the file somewhere other than the CLI-owned output path, the CLI moves it into .devcontainer-preprocessed/Dockerfile.
• That normalized generated file is then used for the normal image build, stage parsing, and feature extension flow.