Linux: BadMatch fix when not-yet-mapped windows are focused, rdi_from_dwarf & linux_demon, RD_CmdKind_RunExternalDriverTextCommand fixes

[giovannicarlino04]

Added a wm_window_focus check for the window's map_state (XGetWindowAttributes). If the window is already viewable I set the focus immediately; otherwise I set a pending_focus flag on the LNX_WM_Window.

Added MapNotify in wm_get_events case that handles the request once the window is mapped, clears the flag and flushes...

[giovannicarlino04]

Since my last commit: Fix ELF phdr addressing and DWARF5 relative directory paths

• linux_demon: use the base_vaddr value to calculate module_phdr_vaddr
  rather than the module_rebase (since the ELF header is always
  loaded at the base_vaddr address, regardless of whether the module
  is PIE or not. The previous calculation would yield an invalid
  value for the program header address when the
  module is not PIE (ET_EXEC) and module_rebase is 0).

• rdi_from_dwarf: prepend the compilation directory (dirs[0]) to a
  DWARF5 line table directory entry in case it is relative.
  GCC generates relative subdirectory entries for the primary
  source file (for example, "src" in gcc src/main.c) and the
  absolute path ("src/main.c") would previously be determined based
  on the relative path only.

[giovannicarlino04]

For my last commit: 2391e11

RD_CmdKind_RunExternalDriverTextCommand always passed any non-flag text in
the message into the command’s primary argument slot using the exact same
default case handling as RD_RegSlot_FilePath. In the case of commands
using RD_RegSlot_Null (such as run_to_line and add_breakpoint), this fill
would still happen with an empty string, setting file_path to "" and
line_num to 1, silently overriding whatever file_path:PATH:LINE flag had
just been set to. Modified to prevent the fill so it does not happen if the command has
no primary slot.

[giovannicarlino04]

For my last commit:

In rdi_from_dwarf, I noticed emit_line was being reset only when a row passed the "address != 0 && line != 0" filter, so a "DWARF line == 0" marker left it dangling into register only opcodes found later. If one of those made the line non-zero again, a bogus row was added at the address left from the skipped opcode instead of where that line actually began, shifting breakpoint addresses. Clang commonly emits this opcode sequence; gcc doesn't (at least from my tests, it always worked fine).

DW_AT_low_pc/high_pc range computation had the address class/constant class branches swapped. Whenever high_pc used a constant class form, the raw value was used as an absolute voff instead of being added to low_pc, truncating the registered address range of the unit, routing any PC past that point to the an empty unit, so line lookups for
addresses in the back half of a compile unit's code (main() and others in my tests) returned no source line.

Also, in disasm, the disassembly view inline source used RDI_SourceFile.normal_full_path, it is lowercased for case insensitive matching, to actually open the file from disk on POSIX I reconstruct the real-case path from the file path node tree instead.