RISC-V: Distinguish physical & virtual test environments

What

A small refactor to distinguish between the riscv test environments.

Why

There are two riscv test environments, given by -v- & -p- tests, referring to virtual memory addressing or physical memory addressing.

The environments have different mechanisms to perform an ecall to the execution environment, as can be seen in the following macros: virtual, physical

# Physical memory tests
#define RVTEST_PASS                                                     \
        fence;                                                          \
        li TESTNUM, 1;                                                  \
        li a7, 93;                                                      \
        li a0, 0;                                                       \
        ecall

#define RVTEST_FAIL                                                     \
        fence;                                                          \
1:      beqz TESTNUM, 1b;                                               \
        sll TESTNUM, TESTNUM, 1;                                        \
        or TESTNUM, TESTNUM, 1;                                         \
        li a7, 93;                                                      \
        addi a0, TESTNUM, 0;                                            \
        ecall

# Virtual memory tests
#define RVTEST_PASS li a0, 1; scall

#define RVTEST_FAIL         \
        sll a0, TESTNUM, 1; \
1:      beqz a0, 1b;        \
        or a0, a0, 1;       \
        scall;

How

Split the posix module into "types" of environments, keeping the initial one to do the housekeeping while introduced a PosixHandler of type RiscVTest.

Introduced a new generic parameter when specifying the posix environment (PosixHandler trait), so this choice is apparent directly from the type. It introduces a few marker fields and an extra generic parameter for some structs. Open to suggestions if the choice of type of environment can be done in other ways.

Manually testing the MR

cd src/risc_v && cargo test

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR