Vector instructions that process IEEE 754 binary16 numbers were included
in draft versions of the vector extension, but they were separated from
the V extension prior to ratification.  This PR adds them back.

The Zvfh extension adds IEEE 754 binary16 support to all FP instructions.

The Zvfhmin extension adds only the conversions to and from binary32.

This makes it easier to reference them.

* Clarify Zve* extensions

* "does not include" instead of "exclude"

* verb conjugation

While it is technically correct to use 2^(XLEN-1) here
and say 2^16 there, it invites confusion.

Eliminate conflicting interpretations or mathematical errors
by stating the exact limit of VLEN (and thus VLMAX).

Following up on 9a877e85,
add the note that Zvl* composes with V, and that Zve*
can compose with each other.

Some users have interpreted this spec to imply incompatibility between
Zve* and V (see e.g. https://reviews.llvm.org/D117854).

That's not the intent, and hopefully this patch clarifies that fact.

Follow-up to e0675aa7

Co-authored-by: lhtin-rivai <lehua.ding@rivai.ai>

Resolves #756

Make encodings reserved if the same vector register would be read with two or more different EEWs by the same instruction.

Moved discussion of illegal `vtype` values into section on configuration setting instructions, and expanded explanations.

Once ratified, we will provide nomenclature for the relationship
between vector extensions and Zfinx.  However, we'll need alternate
extension names: e.g., Zve32fx might correspond to Zfinx.

Resolves #741

Revert "Revert "Added Annex 'Fractional LMUL example'""

Revert "Added Annex 'Fractional LMUL example'"

Added Annex 'Fractional LMUL example'

Revert "Fix implementation of strncpy"