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

[AlexJones0]

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[<NIL>] 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.
5. %!s: String with length.
   Using LOG_INFO("%!s", 7, "test_string_test"); logs test_st in C, whereas this is logging dump ¾¼î¿½ in DV.
6. %%: An escape for printing a percent character.
   Using LOG_INFO("%%"); logs % in C, whereas this is logging as %% in DV simulation.
7. %!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.
8. %!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.