[rocketv] Interlock vector .vf ops against an in-flight scalar FP producer

[emiliengnr]

Hello, here is a pull request for a bug I found.

A vector .vf instruction reads its scalar operand from an f register
(vectorReadFRs1). The three FP data hazard checks fpDataHazardEx/Mem/Wb gate on
the fp decode bit, which a vector instruction does not set, so a .vf reader was
not held for an f-register producer (fmv.w.x, flw, ...) only one or two stages
ahead. The scalar core then handed the vector unit a stale frs1 and the whole
vector instruction computed on the wrong scalar. With zero or one instruction
between the producer and the .vf reader the value is stale; with two or more it
is correct.

The scoreboard stall (idStallFpu) and fpu.valid already combine fp with
vectorReadFRs1; only these three EX/MEM/WB checks were missed. Add the vector
read of frs1 to the same three checks. This only adds interlocks that were
missing and matches the scalar FP path exactly, so it cannot introduce a wrong
result.

Found by differential testing against spike (T1 offline difftest). A vfdiv.vf
whose divisor is set by an fmv.w.x immediately before it reads the register as
its reset zero, so every active element becomes +/-inf; the fix makes it read the
written value. Verified on a rebuilt blastoise emulator, including a gap sweep
(0-1 gap stale, 2+ correct) and a 24-program random batch with no regression.