fix: repair the 10 test files that were failing for unrelated reasons

[metif12]

Follow-up to #195. That got the build and make testfmt green; this brings
make test from 37/47 to 46/47. The one remaining failure is shuf_test.v,
which is issue #189 and gets its own PR.

common/pwd: group ids came back as garbage

getgrouplist() and getgroups() fill an array of gid_t, which is 32 bits
wide, but the V declarations handed them a []int, i.e. i64. The kernel wrote
the low half of each slot and left the upper half holding the previous entry, so
gids arrived as 103079215108 — that is 24 * 2^32 + 4, i.e. adm's 4 with
cdrom's 24 sitting above it:

$ groups
GNU: mr adm cdrom sudo dip plugdev users docker
before: mr adm sudo plugdev mr root root root root

Both functions now fill a []u32.

getgrgid() was also declared as returning &C.passwd instead of &C.group.
That only ever worked because gr_name happens to sit at the same offset as
pw_name; gr_mem and gr_gid do not line up. There is now a proper struct.

groups and id now agree with GNU for the plain, named-user, -nG and -G
forms.

tail: KiB was decimal, and PB/EB used the binary multiplier

The suffix table mapped both kb and kib to 1000, both mb and mib to
1000^2, and so on — so tail -c 1KiB read a third of what it should have.
petabyte was also terra * kilo and exabyte peta * kilo, i.e. the binary
multipliers, instead of continuing the decimal chain. The two chains are now
separate and correct, and the test asserts GNU's actual values instead of
mirroring the constants back at itself.

The overflow check was result == 0 && number != 0, which cannot catch a
wrapped product; it now checks the division comes back out, so 20E is rejected
the way GNU rejects it. Z/Y/R/Q stay unsupported: although GNU's help mentions
them, GNU itself rejects every one with "Value too large for defined data type"
(checked against 9.4).

Verified end to end against GNU for 2b, k, K, KB, KiB, M, MB,
MiB, G, GB, GiB, T, TB, TiB, P, PB, PiB, E, EB, EiB,
plus the rejection cases.

numfmt: 2000.0 and 2e+06

f64.str() always keeps a fractional part and switches to scientific notation
above a million, so --to=none 2000000 printed 2e+06 and 2K printed
2000.0. Both go through a helper based on strlong() that drops a trailing
.0.

stat: the default Device: field

The default format used %Dh/%dd, printing the device number in hex over the
same number in decimal — 830h/2096d where GNU prints 8,48. GNU's default is
Device: %Hd,%Ld, and %H/%L are two character tokens that
scan_for_tokens() did not handle; there was already a TODO about it. Both are
implemented and the default format now matches.

Four tests were asserting the wrong thing, or crashing

• tail_test and fmt_test captured &result for a local in setup() and
  returned the closure. Once setup() returned the pointer dangled and the
  closure appended to freed stack memory:

  malloc_uninit(0xd0a07408218d1b1f < 0)
  V panic: memory allocation failure
  

  The array header is now heap allocated. (cut_test and paste_test use the
  same shape but call the closure in scope, so they are fine.)

• string_to_i64_test used ! on an option return, which does not compile.

• sum_test had const util next to import io.util; the import is aliased.

• truncate_test computed its expectations as 24 * 1000 * 1000 * 1000. V's
  int is 32-bit, so the expectation wrapped to -1769803776 while the
  value under test, a u64, was right all along. The expectations are now u64.

Testing

• v run build.vsh — all 76 utilities build
• make testfmt — passes
• v test . — 46/47 files pass, up from 37/47

Verified on V 0.5.2 (0dc6a69, upstream vlang/v master), Ubuntu 24.04, GNU
coreutils 9.4.