Clarify when mtvec.mode should be included in representability check

[tomaird]

The description for mtvecc has the following:

From these two highlighted sections, it's a bit unclear when writing to xtvecc whether the representability check should be done on

1. mtvecc.address (including mode bits) - this is the address that is visible to SW
2. OR {mtvecc.address[MXLEN-1:2], 2'b00} - this is the address that is actually jumped to (for non-vectored traps)
3. OR both of the above

(Obviously when MODE=vectored we also do the representability check on {mtvecc.address[MXLEN-1:2], 2'b00} + 4 * HICAUSE - but that is more clear, since we're checking the maximum possible vector target is in range.)

[tariqkurd-repo]

Yes - this is clearly wrong - the rep check where the MODE is set to Vectored has the LSBs set to 2'b01, but the address jumped to on exception always has the LSBs set to 2'b00.
In very weird cases, it's possible for the value in mtvecc to only be representable when the LSB is set.
Therefore we must be clear that the address range checked for representability must include all possible exception vector addresses.

[arichardson]

We also don't specify whether you can use a sentry in direct mode. I am not sure if this is something that should be supported by unsealing on trap (@jrtc27 @nwf)?