VHDL port of RoCEv2 engine

[FilMarini]

[WIP] VHDL port of the RoCEv2 RDMA transport-layer engine

Summary

SURF currently pulls in the RoCEv2 RDMA transport-layer engine as pre-generated
Bluespec/Verilog. This PR is an early, in-progress effort to re-implement that
same engine natively in VHDL, following the SURF coding standard (two-process
FSMs, RegType/REG_INIT_C register pattern, sl/slv typing, SURF-provided
FIFOs/AXI components wherever applicable, etc.) and reusing SURF
library components instead of hand-rolled equivalents wherever one exists.

The goal is a drop-in, native-VHDL alternative to the current Bluespec-sourced
core — same protocol behavior (RC queue pairs, SQ/RQ request and response
handling, retry/NAK, DMA read/write arbitration, RDMA header generation and
parsing, etc.), but expressed directly in VHDL and integrated with SURF idioms
rather than wrapped Verilog.

This PR is being opened purely for visibility into ongoing work — it is not
ready to be merged or used.

Current status: early development, not usable yet

• The engine is being translated module by module, leaf-first through the
  dependency hierarchy, so that each block's interface is verified against its
  submodules before the next block up is attempted.
• A large portion of the module hierarchy has an initial VHDL emission,
  including top-level integration points (TransportLayer, and an AXI-Stream/
  AXI-Lite wrapper TransportLayerAxi intended to sit alongside SURF's
  networking stack).
• Most emitted modules have an accompanying per-module testbench, and many of
  these pass in isolated simulation. Some modules and interactions are still
  unverified.
• Beyond per-module testbenches, there is ongoing full-system testing:
  simulating the top-level wrapper against a real SoftRoCE peer over a
  scapy-mediated network bridge, exercising the RC retry/NAK state machine
  under induced packet loss. This has already surfaced and fixed several
  correctness bugs, and continues to surface more.
• Known gaps / open items are tracked inline as the work proceeds (open
  questions on ambiguous BSV constructs, generic-width conventions, missing
  coverage, etc.) and have not all been resolved yet.

In short: significant parts of the design translate and simulate correctly
in isolation, but end-to-end correctness, full hardware testing, and coverage
of edge cases are all still in progress. Please do not treat this as a
replacement for the existing BSV/Verilog core yet.

Why open the PR now

Mainly to make this effort visible to anyone working in this area, invite
early feedback on direction/style, and avoid duplicated work. Happy to discuss
approach, naming conventions, or how this should eventually be structured
relative to the existing core.