Partially introduced by 7f45777b and 94ab414c4b470edae8bde4e7759163fe7ddf8ab4

The spec says that the platform will define which exceptions must populate
mtval or stval with a nonzero value and which are permitted to zero it.
But then later statements seem not to permit the possibility of zeroing
the register, which is a contradiction.  Resolve in a backwards-compatible
manner by permitting zeros unless the platform says otherwise (which was
the original intent, anyway).

This permits e.g. zeroing mtval on an EBREAK instruction, where mepc
provides sufficient information, as was the intent of 94ab414c4b470edae8bde4e7759163fe7ddf8ab4.

The description of FENCE.TSO as "optional" was incorrect.  It has always
been a mandatory instruction (because of the requirement that unused
patterns in the fm field be treated as though fm=0).

Related to forthcoming Svpbmt extension.

* Changes to SSIP to support forthcoming interrupt controllers

* Re: SSIP, say more by saying less

* Speculative implicit reads, v2

These constraints are better expressed as PMAs, and so we relax the
unprivileged spec to always allow speculative implicit reads "unless
otherwise specified", then move the constraints into the PMAs.

This proposal piggybacks on the non-idempotence PMA, constraining implicit
reads to within a power-of-2 region of a non-speculative implicit read.
Furthermore, speculative instruction fetch can also access the subsequent
power-of-2 region.

* Add preface entry

Thanks to @YenHaoChen.

Closes #731

Add mseccfg and *envcfg CSRs

Raise a virtual instruction exception when V = 1 if an attempted 
instruction is HS-qualified but is explicitly blocked by either a 
hypervisor CSR or a supervisor CSR.  Previously, the document was 
inconsistent whether an illegal instruction or virtual instruction
exception is raised when an instruction is blocked from executing in
VU mode solely by a supervisor CSR such as scounteren.

Writing the low part does not disturb the high part and vice versa.

When different privilege modes have different values for XLEN, the
terms _RV32_ and _RV64_ are not sufficient to indicate the width of a
privileged CSR that is accessed from a more-privileged mode (e.g. when
32-bit vsatp is accessed from 64-bit HS mode).  Where needed, replace
"RV32" and "RV64" with more specific references to the correct XLEN.

This reverts commit 8551bd20
at @kasanovic's request.

* Add Smdisc extension (i.e. mconfigptr CSR)

* mconfigptr may be hardwired to zero

* Add changelog entry for mconfigptr

* Fix mconfigptr preface entry

"points to the address of" implies an extra level of indirection.
Should be "points to" or "contains the address of"

Make the manual more correct and consistent by dropping the term
_execution environment interface_ and its abbreviation _EEI_ and
replacing them everywhere with just _execution environment_.