Add option to configure physical address width

[iamkarthikbk]

Issue description

Spike currently hardcodes the physical address width based on XLEN:

// processor.h:251
unsigned paddr_bits() { return isa.get_max_xlen() == 64 ? 56 : 34; }

This means RV64 always uses 56-bit physical addresses and RV32 always uses 34-bit. However, the RISC-V Privileged Spec (Section 3.7.1) explicitly allows implementations to support fewer physical address bits:

"Not all physical address bits may be implemented, and so the pmpaddr registers are WARL."

Implementations can use narrower physical address spaces (e.g., 32-bit PA on RV64 cores without virtual memory). When validating such designs against Spike, PMP behavior diverges because:

1. Software writes a large value to pmpaddr
2. Spike stores the full value and uses it for TOR/NAPOT matching
3. The RTL's WARL can truncate it and the PMP checker uses the narrower address — producing different match results
4. Instruction/data access fault behavior diverges

There is no way to configure Spike to match the implementation's physical address width, making it harder to use Spike as a reference model for these cores.

Proposed change:

Add a --paddr-bits=<n> command-line option.

• cfg.h: add unsigned paddr_bits; field
• cfg.cc: default to 0 (meaning use current behavior: 56 for RV64, 34 for RV32) -- Is there a better way to do this ?
• processor.h: change paddr_bits() to return the configured value, falling back to the current default when 0
• spike_main/spike.cc: add CLI parsing and help text

The existing paddr_bits() method is already used everywhere that matters (pmpaddr masking at csrs.cc:124, SATP PPN mask at csrs.cc:1111, HGATP mask at csrs.cc:1339), so no other code changes are needed for this particular config option.