[vector] java doc for iota()

[John Rose]

P.S. The net of my previous two messages (sorry for the stream-of-consciousness-blast format)
is that shuffles should have one extra bit per lane to represent non-fully-wrapped values,
and that shuffle lane values should have *no additional visible informatiton*, even if they
have extra physical storage bits someone might want exploit somehow.

One other point:  In insisting that 256-lane byte vectors not self-support their shuffles,
I’m aware that someone (including me) can say, “the obvious efficient representation
is the same vector layout, with 8 bits per shuffle index; you are being too idealistic here”.

The answer to this objection is simple:  You are always going to run into this limitation,
sooner or later.  A vector’s lane size may be too small, and/or its length (its ceil-lg)
may be too small, so that the vector cannot host its own shuffles.  It’s a fact of life we
will run into sooner or later, and if we add the “partial” bit we run into it slightly sooner.

“But, but, SVE worked so hard to allow *all* their vectors to host their own shuffles.
See, 2048/8 = 256!”  Sadly, even if we made some sort of exception for this edge
case, we’d just sign ourselves up for a second exception, because *Java has no
8-bit unsigned type*.  This means that those clever SVE vectors cannot be vectors
of byte, since the dynamic range of byte is [-128..127].  The best a Java byte can
do is to represent a lane in a *partially wrapped* shuffle (this is consilience BTW)
of a vector of VLENGTH <= 128.   SVE has lovely unsigned types, and Java can’t
catch up yet with those, until we reach Valhalla and extended numerics.

So, I claim the proposed design for shuffle indexes (including the partial bit)
is neither too much nor too little for all known uses, *and* it does not, all by itself,
unduly burden the extreme cases of SVE.