SP and RoT need to coordinate on firmware rollback decisions

When "trying out" new SP firmware, we may need to decide it's crap and cancel the upgrade, flipping back to the other image slot (which presumably still contains the previous assumed-okay firmware). We currently don't have a mechanism built for this.

The RoT will wind up having to be in charge, due to our use of the RoT as a sort of "external bootloader" for the SP. Painting in broad strokes, some things we may need here are

1. A way for the SP to report "I am totally hosed and cannot boot" to the RoT. Currently this has to be a SPI message since we don't have a "boot failure" net from SP to RoT (though adding one in the future would rock). This implies that the SP needs to be able to detect things being hosed, and generate that message -- more on that in #1206.
2. A way for the control plane to tell the RoT to stand down. This would be the best end-to-end verification that an SP image is adequate: that it has convinced the control plane it's ok, and has received a message from the control plane agreeing.
3. Code that monitors these two sources, plus the SP reset pin (which will be pulsed by the SP on a watchdog reset), to decide whether to flip banks back on the next reset, or to stand down. A failure (explicit or unexpected reset) would cause flip-back exactly once; standing down would cause further resets to not cause flip-back.

No file, test, or entry point is named in the issue. Start by reading issue #1206 and tracing the SP/RoT firmware-update and reset paths. Done means the SP can report failure, the control plane can approve the image, and the RoT makes the specified one-time rollback decision.