Don't enable esp-hal/unstable in esp-storage

[bjoernQ]

This technically fixes #5875 - at least we are not violating our own guidelines anymore

For stabilization we will need a way to not rely on anything unstable - but that's a problem to solve for the stabilization story

[bugadani]

requires-unstable can go to esp-hal, no need to repeat it

[bugadani]

What do we need to stabilise, besides p.FLASH? Do we intend to stabilise esp-bootloader-esp-idf, or just esp-storage? If only one, how will we access partitions in stable code? If both, how will we introduce other bootloaders later, if we do everything in esp-hal still? We probably have a few questions to explore, still.

[bjoernQ]

What do we need to stabilise, besides p.FLASH? Do we intend to stabilise esp-bootloader-esp-idf, or just esp-storage? If only one, how will we access partitions in stable code? If both, how will we introduce other bootloaders later, if we do everything in esp-hal still? We probably have a few questions to explore, still.

I guess we want to stabilize the API of both - at least most of it

We currently use

• peripherals::FLASH, CPU_CTRL, CpuControl, is_running
• efuse::flash_encryption()
• peripherals::MMU_TABLE
• peripherals::SPI1::regs()

A lot can just be turned into PAC access. Also the efuse thing seems innocent.

[bugadani]

CPU_CTRL, CpuControl, is_running - multi-core functionality can be hidden behind esp_hal::if_unstable_hal! - with stable HAL, there is no chance of someone enabling the second core, so we don't need to deal with that problem.

[github-actions]

New commits in main have made this PR unmergeable. Please resolve the conflicts.

[bjoernQ]

aha - esp-bootloader requires esp-storage which requires unstable so the tests which don't enable esp-hal/unstable fail to build

but ... we cannot have tests without esp-bootloader since we need that macro

not sure what we want to do here now (and previously having esp-storage unconditionally enabling esp-hal/unstable means those tests technically never were testing only stable 🤔 )

@MabezDev given we might decide on moving things to esp-hal we might want to just close this PR knowing it will get sorted out by itself

[github-actions]

New commits in main have made this PR unmergeable. Please resolve the conflicts.