configure.ac and cmake/ConfigureChecks.cmake's TX_RING probe has the same header collision src/common/txring.h had

[fklassen]

Describe the bug

#1043 fixed `src/common/txring.h` to stop including `<netpacket/packet.h>` alongside `<linux/if_packet.h>` - before C23, the two headers can't be included together (both define `struct sockaddr_ll` and `struct packet_mreq`, and the `_UAPI_DEF*` de-duplication guards don't apply pre-C23):

```
linux/if_packet.h:14:8: error: redefinition of 'struct sockaddr_ll'
linux/if_packet.h:297:8: error: redefinition of 'struct packet_mreq'
```

That fix is real and necessary, but not sufficient on its own: both build systems' own `TX_RING` feature probes independently include both conflicting headers, so the probe itself fails to compile under `-std=gnu11`/`-std=gnu17` (verified directly - reproduces the identical redefinition errors) - meaning `HAVE_TX_RING` never gets defined in the first place on affected systems (the openSUSE/Fedora-style "older language level" case #1043 called out), and `txring.h`'s now-correct `#ifdef HAVE_TX_RING` block never even gets reached.

• `configure.ac` (autotools), around line 1587:
  ```
  AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
  #include <sys/socket.h>
  #include <netpacket/packet.h>
  #include <net/ethernet.h>
  #include <netinet/in.h>
  #include <linux/if_packet.h>
  ]], [[
  int test;
  test = TP_STATUS_WRONG_FORMAT
  ]])],...
  ```
• `cmake/ConfigureChecks.cmake`, the `HAVE_TX_RING` `check_c_source_compiles()` block:
  ```
  check_c_source_compiles("
  #include <sys/socket.h>
  #include <netpacket/packet.h>
  #include <net/ethernet.h>
  #include <netinet/in.h>
  #include <linux/if_packet.h>
  int main(void) { int test = TP_STATUS_WRONG_FORMAT; return test; }
  " HAVE_TX_RING)
  ```

Verified locally: with #1043's fix applied but neither probe touched, `Linux TX_RING:` still printed `no` on a system defaulting to `-std=gnu17` (GCC 14), for exactly this reason.

Proposed fix

Drop `<netpacket/packet.h>` from both TX_RING probe test programs (it supplies nothing the test needs - only `TP_STATUS_WRONG_FORMAT`, from `<linux/if_packet.h>`), matching the same fix already applied to `txring.h`. The separate `HAVE_PF_PACKET`/PF_PACKET probes, which only include `<netpacket/packet.h>` and never `<linux/if_packet.h>`, are unaffected and don't need changes.

[fklassen]

Fixed in #1045, now merged into `v4.6.0-beta1`.

Both build systems' `TX_RING` probes had the redundant `<netpacket/packet.h>` include dropped, matching the fix already applied to `txring.h` in #1043. Fixing the probes then surfaced a third instance of the exact same collision - never hit before, since `HAVE_TX_RING` had literally never been true in any prior build - in `src/common/sendpacket.h`/`sendpacket.c`, which each unconditionally include `<netpacket/packet.h>` whenever `HAVE_PF_PACKET` (and, in `sendpacket.c`, `HAVE_LIBURING`) is set. Both are commonly true alongside `HAVE_TX_RING` on a modern Linux system. Made those includes conditional on `!HAVE_TX_RING`.

Verified end-to-end with both build systems: `Linux TX_RING: yes` is correctly detected, `tcpreplay` reports `Injection method: PF_PACKET / TX_RING` at runtime, and packets are actually sent successfully through it (throughput ~13x over plain `PF_PACKET send()`).