Use measured DRAM energy (RAPL/EMI) for the RAM component instead of adding it to CPU energy

Is your feature request related to a problem? Please describe.

When a measured DRAM energy domain is available (intel_rapl on Linux, or the Windows Energy Meter Interface added in #1263 — issue #457), the rapl_include_dram option folds the measured DRAM energy into the CPU energy total. Meanwhile, the RAM component keeps reporting its power from the slot-based estimation model (~5 W per DIMM heuristic).

This has two drawbacks:

• Double counting: with rapl_include_dram=True, memory power is counted twice — once as measured energy inside the CPU total, and once as the estimated RAM component.
• Mislabeled attribution: even without double counting, real measured memory energy ends up attributed to the CPU in the output, while the RAM column stays an estimate. Users looking at per-component emissions get a distorted picture.

Describe the solution you'd like

When a DRAM energy domain is available and actually working, use it to power the RAM component instead of the slot-based estimate, and stop adding it to the CPU total:

• On Linux, use the RAPL dram domain; on Windows, the EMI RAPL_Package0_DRAM channel.
• The RAM hardware class would consume the measured energy deltas (same mechanism as the CPU class uses for intel_rapl/windows_emi) and fall back to the current estimation model when no DRAM domain exists.
• Importantly, the fallback must also trigger when the DRAM counter is present but dead: on client CPUs the DRAM domain is often unimplemented and reads a flat 0 W (observed via EMI on an Intel Core Ultra 7 265H: RAPL_Package0_DRAM = 0.00 W while PKG = 3.98 W). A simple check that the counter has incremented after the first measurement interval would do. The DRAM domain is mainly trustworthy on server-class (Xeon) hardware.
• rapl_include_dram could then be deprecated or redefined, since DRAM energy would be reported in its natural place.

Describe alternatives you've considered

• Keep the current behavior and only document that rapl_include_dram moves memory energy into the CPU column and should not be combined with the RAM estimate — cheapest option, but the attribution stays wrong.
• Subtract the estimated RAM power when rapl_include_dram is enabled to avoid double counting, without rewiring the RAM component — avoids the double count but keeps measured memory energy labeled as CPU.

Additional context

Applies identically to Linux (intel_rapl) and Windows (EMI, #1263) since both expose the same RAPL domains. Related: #457.

Start by tracing the CPU class's intel_rapl/windows_emi handling and the RAM hardware class's slot-based estimation, then compare Linux RAPL dram with the Windows EMI RAPL_Package0_DRAM channel. Done means working DRAM counters feed RAM, absent or flat counters fall back to the estimate, and rapl_include_dram no longer causes duplicate CPU attribution across both measurement paths.