SPD proxy needs to implement a subset of TSA2004 temp sensor

During PSP boot, it sends messages to the DIMM temperature sensors to configure temperature alerting thresholds. We're currently nacking them. Somewhat surprisingly, it tolerates this just fine and continues the boot.

We probably shouldn't be nacking them. I suggest that we do the following:

• Implement a proxy for the alert threshold registers on the temperature sensors.
• Cache the thresholds it requests
• Asynchronously apply them to the temperature sensors.

We can't synchronously apply them because of SMBus transaction length limitations (in general, you can't recursively SMBus). But, it's not critical that the alert thresholds be synchronously applied, just promptly applied. We can do that. Probably in another task to keep spd available.

We will also need to implement temperature reads. We're not sure what the PSP does with that information, but, it does appear to read it. This will also need to be asynchronous -- we need to get the temperatures separately and then feed them into the proxy. A delayed reading is probably fine. We could, for instance, push them into the spd task from the thermal task over IPC.

Getting this working will be important for having the PSP set up thermal throttling for memory, which seems like a thing we'll want.

Start by tracing the SPD proxy's handling of PSP boot SMBus messages and the alert-threshold registers described in the issue. Then examine how the thermal task could provide temperature readings over IPC; done means threshold requests are cached and applied asynchronously, temperature reads are fed back asynchronously, and the PSP no longer receives nacks.