Fix FIFO delay parameter propagation in HCI

[DanielKellerM]

Summary:
EXPFIFO parameter in hci_interconnect would introduce multicycle delays in the r_valid signal, but the hci_core_r_id_filter module would trigger incorrect assertions even when MULTICYCLE_SUPPORT was active. This created an inconsistency between modules where one parameter was changing what another module should check, without proper parameter propagation.

Proposed Solution:

1. Replaced EXPFIFO with FD (FIFO Depth) parameter: integrated FIFO depth information directly into the HCI package structures for better parameter propagation.
2. Enhanced HCI package and helpers: added FD parameter to hci_size_parameter_t struct and created helper macros for consistent parameter handling.
3. Updated interface declarations: added FD parameter to all hci_core_intf declarations throughout the system.
4. Fixed assertion logic: modified multicycle assertions to exclude FD parameter checks for module port interfaces.

These changes are reflected in Neureka's interface: pulp-platform/neureka#36 (comment)

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[FrancescoConti]

I gave a look while we were speaking. What I am not super much a fan of is that this is a static information which is "similar" to the min-latency from a given point in the HCI system to memory, but it is not quite that.
Notice that the "distance from memory" is actually an important point that has concrete consequences, e.g. the filters need to be at a 0-latency boundary to work properly.
Maybe we can think of a mechanism to embed this information in this parameter, which would make its "carry-over nature" more meaningful to me.

[FrancescoConti]

In any case, this is a breaking change so I would schedule after the previous couple of PRs #61 #60

[FrancescoConti]

@DanielKellerM: with @sermazz we decided to postpone #61 and #60. So this PR is back on the table, I'll give it a new look in the coming days.