ESP32: link via @response files across the family, not just P4

The rak_wismesh_tap_v2-tft link failed on CI with "sh: Argument list too
long": the device-ui bump in #11214 grew the MUI object list enough that
the linker command line crossed the kernel exec arg limit (this env's long
name lengthens every object path, so it tipped first).

extra_scripts/ld_response_file.py already solves this for esp32p4; promote
it to esp32_common so every ESP32 target links through a response file,
and drop the now-inherited entry from esp32p4.ini.

Verified by building rak_wismesh_tap_v2-tft at the failing commit plus this
fix: links clean (macOS's exec arg limit is smaller than the Linux one that
tripped CI, so an unwrapped link could not have passed).

variants/esp32/esp32-common.ini

@@ -17,6 +17,9 @@ extra_scripts =
   ${env.extra_scripts}
   pre:extra_scripts/esp32_pre.py
   extra_scripts/esp32_extra.py
+  ; Spill long link commands into @response files. Big MUI/TFT images exceed the kernel's
+  ; exec arg limit ("sh: Argument list too long"; rak_wismesh_tap_v2-tft hit it first).
+  extra_scripts/ld_response_file.py
 
 build_src_filter = 
   ${arduino_base.build_src_filter} +<platform/esp32/> -<mesh/eth/> -<mesh/raspihttp>

variants/esp32p4/esp32p4.ini

@@ -15,9 +15,10 @@ build_flags =
 build_src_filter = 
   ${esp32_common.build_src_filter} -<libpax/> +<platform/esp32> -<mesh/raspihttp> -<serialization/>
 
+; ld_response_file.py is inherited from esp32_common (promoted there when
+; rak_wismesh_tap_v2-tft outgrew the exec arg limit; it originally shipped here).
 extra_scripts =
   ${esp32_common.extra_scripts}
-  extra_scripts/ld_response_file.py
 
 ; Override esp32_common component pruning: keep esp_hosted + esp_wifi_remote for P4 hosted BT
 custom_component_remove =