Cosmo host flash could drop ownership notion

Currently the Cosmo host rom management looks like Gimlet: it assumes there's a discrete mux on the system that swaps between whether the host can issue commands or the SP. While the initial reasons for making these similar make a lot of sense, this limits our ability to do a lot of different operations, e.g. we can't do writes to the other slot or make changes to the persistent slot while the system is up. However, there's no inherent reason that it has to be this way (though it is a simpler implementation).

Because the host can never write to the SPI flash as this command should be rejected by the eSPI controller, with some help from the FPGA we can change how this actually works and intersperse writes to the non-active region for booting and the slot selection page. Similarly, there is no reason that the SP can't read this while the host is trying to boot. It means there will be more command latency, but there's nothing that says they can't be interspersed.

I realize that this is something that we may opt to never do, but there are some usability and comprehension challenges here for folks. For example, there is no reason to ever hit #2338 on Cosmo's.

Start by tracing the Cosmo host ROM management and comparing its ownership assumptions with Gimlet's discrete mux behavior. Then investigate the eSPI controller, SPI flash regions, slot-selection page, and FPGA coordination; done means defining and implementing a safe approach that permits interspersed SP and host operations without the current ownership limitation.