Value class coverage

[cwssemi]

Extends the declared test values so that a handful of paths the current vectors do not
sensitise are exercised. Motivated by validating a RISC-V vector implementation, where a
couple of decode issues turned out to sit on exactly those paths, so the existing vectors
passed on them.

Three commits, and the third is comments only:

1. extend value coverage for shifts, rotates, saturation and divide — vror.vi at
   uimm >= 32 (its immediate is six bits, the top one funct6[0], so that encoding was
   unreached); the two ends of the simm5 range; operand pairs that reach the saturation
   boundary where none did; INT_MIN / -1; and an operand that separates a shift by 31
   from one by 63 where 0x0 and -1 cannot.

2. add INT_MIN operands to the signed-arithmetic families — 118 configs. Scoped to
   where INT_MIN is the edge case, and deliberately not added to loads, stores, mask
   logic or permutes, where the column is an opaque bit pattern.

3. comment the added value classes — 191 comments across 128 configs explaining why each value is
   there. The configs carry no comments today, so this is a departure from house style.
   It is a separate commit for exactly that reason — drop it if you would rather keep the
   configs as they are, and the first two stand unchanged.

What these values found

Run against a production RVV implementation (Saturn, ucb-bar/saturn-vectors) on the day they
were added, these configs surfaced two silent-wrong-result defects that the existing vectors
pass on. Both were root-caused to one line of RTL each, both fixed and measured:

• vror.vi at imm >= 32 shifts arithmetically. The rotate's shift half sign-extends,
  because the signedness flag is taken from funct6(0) — which means arithmetic for the shift
  family but direction for the rotate family. Reached only by the uimm >= 32 values in
  commit 1; the largest immediate the configs declared before was 31, so object RORI had never
  been executed by a generated test at any SEW.
• vsmul saturates at 32-bit bounds when SEW=64. A Scala Int overflow in a Chisel
  constant: 1 << ((8 << sew)-1) masks the shift distance to 5 bits, so sew=3 clips at ±2^31.
  A genuine saturation returns INT32_MAX instead of INT64_MAX, and a result merely larger
  than INT32_MAX is clipped although the spec does not saturate it, raising vxsat spuriously.
  Reached only by the INT_MIN operands in commit 2.

Neither is exotic. INT_MIN × INT_MIN is the single defined saturation case for vsmul, and
vror.vi has a six-bit immediate of which the configs exercised five bits. Both are the kind of
value a coverage list is for, and in both cases the instruction was already "tested" — the
existing vectors execute it and pass.

Status

Opening as a draft so the repo's own CI runs it: build-and-test.yml does
make generate-stage1 then make all across VLEN 256/128/64 × XLEN 64/32. 128 configs is a wide
change and the goldens are the part worth checking, so I would rather that ran before asking anyone
to look. Ready for review once it is green.

Checks

• Full generate-stage1 passes: 1,612 files, against 1,555 before. Byte-identical
  with and without the comment commit.
• Value typing follows the existing convention — bare hex for base/sew8/sew16/
  sew32, quoted strings for sew64, matching the uint8/16/32 and string fields the
  decoder expects.
• Row width matches each block; the multiply-accumulate forms carry three columns because
  vd is also an input.

Related

Separate from #94 and its PR, which
is a generator change restoring the declared sew64 blocks for the vd,vs2,uimm,vm and vd,vs2,vm
formats. These are config-only and independent, though the two compose: restoring that dimension is
what makes the SEW=64 values here reachable for those instructions.