[p4testgen] Add STF backend for PNA

[smolkaj]

Summary

Adds STF output support for the PNA p4testgen target, matching the
existing BMv2 STF backend. This enables:

p4testgen --target dpdk --arch pna --test-backend stf program.p4

The backend handles exact, ternary, LPM, and optional match types.
One .stf file per test case, same format as BMv2's STF output.

New files: backends/p4tools/modules/testgen/targets/pna/backend/stf/stf.{h,cpp}

The Bazel hdrs glob in backends/p4tools/BUILD.bazel is widened
from backend/*.h to backend/**/*.h so the new backend/stf/
subdirectory is picked up. (Enabling PNA itself in the Bazel build
was originally part of this PR but landed separately via #5575.)

Motivation

The 4ward P4 simulator uses
p4testgen to generate STF tests for PNA programs. Without an STF
backend, --test-backend stf fails with "Unsupported device: dpdk".

Testing

Validated in 4ward: 411 p4testgen-generated STF tests across 21 PNA
programs pass with this change.

@fruffy — would appreciate your review on the STF backend approach.
Happy to adjust anything.

[fruffy]

I think we should split this off into a dpdk and 4ward back end, then you can generate packets for the more pure interpretation of the PNA spec that 4ward has, free from the implementation restrictions of the DPDK target.

But let me also revive #4228 and see how this PR influences it.

[smolkaj]

Thanks for the feedback @fruffy! I've updated the PR to split out the drop-by-default change (will file that separately once the semantics are settled).

What remains here is just the STF backend for PNA — no behavioral changes to existing code. Happy to rename the backend or restructure if you'd prefer a 4ward-specific target down the line, but the STF output itself is target-agnostic (same format as BMv2's STF backend).

Re #4228 — would love to see that land too. This PR shouldn't conflict with it since we're only adding a new backend under targets/pna/backend/stf/.