fix: harden build against empty toolchain output

On some Windows systems, antivirus, endpoint-security or DLP/encryption
software intercepts short-lived toolchain processes and strips their
stdout when the build captures it through a pipe, while the same command
prints its output normally when run by hand. The tool exits successfully
but returns nothing, and each build step that reads toolchain output then
failed with a different, cryptic error far from the real cause:

- CMake configuration aborted with "Unknown arguments specified" in
  components/xtensa/project_include.cmake, or "check_expected_tool_version
  invoked with incorrect arguments" in components/esp_common.
- ldgen turned the empty objdump output into an opaque pyparsing
  "Expected 'In archive'" traceback.
- idf_tools.py silently reported the compiler/debugger version as
  "unknown", sending users into a fruitless reinstall loop.

Detect the empty result at each consumer and fail (or warn) with an
actionable message that names the likely cause and the remedy:

- tools/cmake/compiler_query.cmake: new __compiler_query() helper runs a
  compiler query and fails with a clear error on empty or failed output.
  It is a standalone module included by both the cmakev1 and cmakev2
  utilities, since the esp_common and xtensa project_include.cmake that
  call it are shared by both build systems. The xtensa if() arguments are
  now quoted so an empty result no longer collapses into a parse error.
- tools/ldgen/ldgen.py: _run_objdump() rejects empty objdump output, and
  non-empty-but-unparsable section info is caught and re-raised as a clear
  LdGenFailure instead of a raw pyparsing traceback.
- tools/idf_tools.py: empty version output now warns with the cause and
  returns UNKNOWN_VERSION instead of silently reporting "unknown".

Closes https://github.com/espressif/esp-idf/issues/18727

Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>

tools/idf_tools.py

@@ -998,7 +998,25 @@ class IDFTool:
                 f'non-zero exit code ({e.returncode}) with message: {e.stderr.decode("utf-8", errors="ignore")}'
             )  # type: ignore
 
-        return self.parse_tool_version(version_cmd_result.decode('utf-8'))
+        version_str = version_cmd_result.decode('utf-8')
+        if not version_str.strip():
+            # The tool ran and exited successfully, but produced no output when its
+            # output was captured. On some Windows systems, antivirus, endpoint-security
+            # or DLP/encryption software intercepts short-lived toolchain processes and
+            # strips their stdout when it is captured through a pipe, while the same
+            # command works when run directly in a terminal. Surface an actionable hint
+            # instead of silently reporting the version as 'unknown', which otherwise
+            # sends users into a fruitless reinstall loop.
+            # See https://github.com/espressif/esp-idf/issues/18727
+            warn(
+                f'tool {self.name} ran but returned no version output. This is usually caused by '
+                'antivirus, endpoint-security or DLP/encryption software stripping the output of '
+                'toolchain processes; the same command often works when run directly in a terminal. '
+                'Add an exclusion for the ESP-IDF tools directory in that software. If the problem '
+                'persists, run the tool manually to check for a missing DLL.'
+            )
+            return UNKNOWN_VERSION
+        return self.parse_tool_version(version_str)
 
     def get_version_from_file(self, version: str) -> str:
         """