fix(mspi): fixed possible boot failure in some builds when psram is enabled

A typical scenario is: when XIP on PSRAM enabled, compiler optimization level is Os. Under certain binary layout, boot hangs and backtrace points to `esp_sleep_config_gpio_isolate`.

The root cause is that, during PSRAM initialization, it calls esp_gpio_reserve, which happens to place before the reported function. However, after call, there is no barrier before the clock adjustment in `mspi_timing_enter_low_speed_mode`. The clock gets changed when the cache is still fetching data, resulting in the corrupted data in the end of the cache line.

This commits add spi_flash_disable_cache as a barrier to make sure the cache transactions is finished before the clock switch.

components/esp_psram/device/esp_psram_impl_ap_quad.c

@@ -280,8 +280,8 @@ esp_err_t esp_psram_impl_enable(void)
     psram_set_cs_timing();
 
 #if SOC_SPI_MEM_SUPPORT_TIMING_TUNING
-    //enter MSPI slow mode to init PSRAM device registers
-    mspi_timing_enter_low_speed_mode(true);
+    //enter MSPI slow mode to init PSRAM device registers (early init: see mspi_timing_enter_low_speed_early)
+    mspi_timing_enter_low_speed_early();
 #endif // SOC_SPI_MEM_SUPPORT_TIMING_TUNING
 
     uint32_t psram_id = 0;
@@ -330,7 +330,7 @@ esp_err_t esp_psram_impl_enable(void)
     //Configure SPI0 PSRAM related SPI Phases
     config_psram_spi_phases();
     //Back to the high speed mode. Flash/PSRAM clocks are set to the clock that user selected. SPI0/1 registers are all set correctly
-    mspi_timing_enter_high_speed_mode(true);
+    mspi_timing_enter_high_speed_early();
 #else
     s_config_psram_clock();
     //Configure SPI0 PSRAM related SPI Phases