In the mode in which data is provided to wr_streamers with clk_ref_i,
the timestamps are captured with the clk_ref_i clock. The input data
then crosses domains via FIFO to clk_sys_i clock. The timestamp is
used by FSM in the clk_sys_i domain. The pulse from the timestamper
was expected to happen when the frame is already started to be
generated by the FSM, thus the latch of the tag_valid pulse
(indicating the timestamp was generated) was reseted in the IDLE
state of this FSM. This is OK when the input data and the FSM
are in the same clock domain. IF there is asynch FIFO in between,
it can happen that the timestamp is generated still in the IDLE
state of the FSM... I've changed the reset of the latch to happen
after the timestamp is embedded in the header (i.e. in the
FRAME_SEQ_ID state).

In case the data was received in clk_ref_i domain, the flush_p1_i
was also received in the clk_ref_i domain. However, it was used
in an FSM that works in the clk_sys_i domain. This could cause
problems, for example missing the flash_p1_i pulses, thus frames
not being sent when requested. It was easily seen in the
spec_fixed_latency-demo testbench. In principle, the tx_flush_p1_i
does not need to come with data, can be asynchronous to data.
It should be a pulse, yet it can happen that it is constantly high
(see Tom's testbench of fixed-latency mode). Thus in cross-domain
use case :
1. first the pulse is extended to to cycles
2. thanks to this, the gc_sync_ffs module can be used to
   pass the signal to clk_sys clock domain, whether it is a
   pulse or not.

The fixed-latency mode was triggered in the case of receving incorrect
timestamp. This was not correct.

the incorrect_timestamp bit was not evaluated when arming fixed
latency mechanism. This could cause an erronous timestamp to
trigger fixed-latency mechanism

This happened after the fixed-latency mode was first enabled
and then disabled.

one register was not re-setted and so when the fixed latency
was set and then it was unset, the frames would be counted
as "late frames", incorrectly.

Instead of adding another generic to streamers that later needs to
be propagated outside of Board Support Package and potentially for
each board, the choice of clock (clk_sys_i or clk_ref_i) is included
in the record of generics for tx/rx path of streamers. Indeed,
theoretically, such choice can be done per-path (rx and/or tx).

- added comments
- removed white spaces and unnecessary lines
- aligned text

NO FUNCTIONAL CHANGES

- updated components declarations in package files
- removed double-setting of registers (control of registers
  was moved from one process to the other)