Clarify the consequences of vxsat not being handled by the intrinsics

[rofirrim]

Clarify the consequences of vxsat not being handled by the intrinsics

[nick-knight]

@dzaima I agree with a more general comment, that this API spec doesn't need to discuss any of the V-extension architectural state, in the same way that the C language specification of <fenv> doesn't mention frm and fflags. Said differently, you could write a C compiler that retargets RVV intrinsics at a non-RVV ISA, emulating everything.

This type of discussion might be relevant in an ABI document, or a document about mixing RVV intrinsics and inline asm, but the RVV intrinsics spec (intentionally) avoids both of these topics.

In the case of this PR, we are responding to a request from the RVI Architecture Review Committee that is blocking ratification of this spec. Rather than philosophizing and bickering with the ARC about what truly belongs in a C API spec, we decided it was more expedient to just simply implement their request, which amounts to expanding a (non-normative!) note that existed already.

[rofirrim]

Earl Killian from ARC suggests that

Might I suggest that you specify for the intrinsics that would affect vxsat, that vxsat is UNSPECIFIED after execution of the intrinsic (to allow forward compatibility with whatever may or may not be done on the future to more properly support vxsat)?

[dzaima]

As a side-note, I wonder if it even makes sense for intrinsics to state anything about the vxsat CSR - clang already can autovectorize plain scalar code to vxsat-modifying code, so it's already the case that basic regular C arithmetic can modify vxsat, thus making intrinsics also doing such moot.