Trap Handler Issue in S Mode with Virtualization Enabled

[Ammar-10xe]

Issue Description

There's an issue related to the behavior of the trap_handler when handling exceptions in S mode with virtualization enabled.The issue manifests itself in two distinct scenarios:

1. Scenario 1: When handling exceptions in S mode with the mdeleg specific bit set for a particular exception, and virtualization is turned off, the trap_handler functions correctly.

2. Scenario 2: The problem arises when an exception occurs during virtualization enabeled, and the mdeleg specific bit is set to a high value.

Expected Behavior:
The expected behavior is that the trap_handler should consistently handle exceptions in S mode, regardless of whether virtualization is enabled or not. In Scenario 2, where virtualization is active, the trap_handler should continue to function correctly even when the mdeleg specific bit is set to a high value.

Current Behavior:
However, the current behavior of the trap_handler does not align with this expectation. It results in an inconsistency in how exceptions are managed between Scenario 1 and Scenario 2.

[allenjbaum]

We have been working on this one for a while. 
This is related to issue #374
A fix is in progress; just reviewing it now.
When we get a PR ready to go, I'll ask you test it out.
But... there are currently no support in Sail for the H-extension yet, so: how are you testing this?
There is a requirement if you are running your own tests: defining RVTEST_VTRAP_ROUTINE to enable the VS mode trap handler.

[UmerShahidengr]

@allenjbaum , @Ammarkhan561 is working with me on checking trap handler in S-mode (in bare mode and in virtual mode).
We have identified a few potential bugs related to the save area, sp register value updates, and behaviour of scratch register in virtual mode. I am in the middle of typing an email to you explaining the whole situation.
So far, we haven't enabled HS mode, this issue is logged to track the potential bugs in trap handler in S-mode only.

[UmerShahidengr]

This issue has been resolved by PR #401