[dv,sw] DV logging backdoor does not correctly process several formatting specifiers

Nobody has claimed this yet.

### Description

This issue is related to #20139, and was discovered whilst testing the implementation of support for logging `%r` in DV simulation.

It turns out, upon further investigation, that a lot of the formatting specifiers are not working correctly in DV simulation, but this was never caught as these specifiers were rarely / never used. The broken specifiers include, **in order of severity**:
1. `%d` and `%i`: Signed integers. SV is interpreting all passed values as unsigned.
Using `LOG_INFO("%d %i", -3, -4);` logs `-3 -4` in C, whereas this is logging `4294967293 4294967292` in DV.
2. `%!b`: Boolean.
Using `LOG_INFO("%!b", 1);` logs `true` in C, whereas this is logging `1[]` in DV.
3. `%r` and `%!r`: `status_t` displayed normally and in JSON format.
Using `LOG_INFO("%r %!r", DEADLINE_EXCEEDED(), DEADLINE_EXCEEDED());` logs `DeadlineExceeded:["AES",45] {"DeadlineExceeded":["AES",45]}` in C, whereas this is logging `%r %!r` in DV.
4. `%C`: FourCC (Four Character Code)
Using `LOG_INFO("%C", 20);` logs `\x14\x00\x00\x00` in C, whereas this is logging `^T` in DV.
6. `%!s`: String with length.
Using `LOG_INFO("%!s", 7, "test_string_test");` logs `test_st` in C, whereas this is logging dump `¾¼î¿½` in DV.
7. `%%`: An escape for printing a percent character.
Using `LOG_INFO("%%");` logs `%` in C, whereas this is logging as `%%` in DV simulation.
8. `%!x` and `%!X`: Lower- and upper-case hexadecimal with length.
Using `uint32_t val = 0xA; LOG_INFO("%!x", 4, &val); LOG_INFO("%!X", 4, &val);` logs `0000000a` and `0000000A` in C, whereas this is logging as `4[268566276]` and `4[268566276]` in DV simulation.
9. `%!y` and `%!Y`: Lower- and upper-case *little endian* hexadecimal with length.
Using `uint32_t val2 = 0xAB00; LOG_INFO("%!y", 4, &val2); LOG_INFO("%!Y", 4, &val2);` logs `00ab0000` and `00AB0000` in C, whereas this is logging as `4[268566272]` and `4[268566272]` in DV simulation.

There are also some small mismatches, such as pointer logging `LOG_INFO("%p", 11);` logging `0x0000000b` in C but just `b` in DV, or as upper hexadecimal logging `LOG_INFO("%H", 0xF);` logging `F` correctly in C but incorrectly logging `f` in DV, but these are less concerning.

One potential way to address this issue would be to introduce System Verilog logging logic identical to that in `sw/device/lib/runtime/print.c`, but then we have a large duplication in logic and increase the burden of maintenance, plus potentially introduce new bugs. A better solution that would maintain the logging backdoor (for simulation speed-up) would be to introduce a DPI for logging in the System Verilog, such that the exact same C code can be used and we can ensure compatibility between DV logs and non-DV logs.

Start by reading sw/device/lib/runtime/print.c and locating the DV SystemVerilog logging backdoor and its formatting path. Compare the listed specifiers and outputs between regular C logging and DV simulation, then determine how compatibility can be tested and maintained, including the proposed DPI direction. Done means the documented mismatches are resolved or explicitly covered by tests.

Written by the indexing model from the issue text.