Hardware/Firmware constant #include file cleanup

[joelsmithTT]

UMD contains architecture-specific header files that live under src/firmware/riscv; these headers define hardware and firmware constants. UMD's use of these constants follow a pattern: the application or unit test fills out structs (e.g. tt_device_l1_address_params, tt_driver_eth_interface_params, etc.) and passes them into the tt_SiliconDevice.

There are some problems with how this is implemented:

• Metal contains its own versions of these files (some of which have diverged from UMD's copies)
• UMD's copies contain constants that are unused (artifacts from legacy software)
• There is opportunity for confusion (for example: what is the correct address for Tensix L1 barrier?)

To better understand how best improve this situation, it would be useful to know the following. Out of the parameters UMD gets from eth_interface.h, eth_l1_address_map.h, host_mem_address_map.h, l1_address_map.h, and noc_parameters.h, which are:

• actually used by UMD (not just passed in, but used by code)
• hardware-defined
• firmware-defined, and may change in the future if e.g. base Eth firmware is restructured
• firmware-defined, but will never change

[joelsmithTT]

Some analysis is captured at https://docs.google.com/document/d/1UBjhn9C-ivxPAFu-7u0fTunNDFRltTiZIRd8XgAsYgo/edit?tab=t.0