stability of configuration options

[MabezDev]

I can foresee us wanting to try out some configuration options, like in #3054 but don't want to commit to having it around forever.

This could be a simple as documenting the stability, but maybe we should prefix unstable configs to make it more clear? ESP_HAL_CONFIG_UNSTABLE_PLACE_SPI_DRIVER_IN_RAM or something like that?

[bugadani]

We also have the option to gate configs by the unstable feature, it's just a matter of cfg-ing compiler_error! calls, or option_env unwraps.

[Dominaezzz]

It would be a good idea to also take into account how stabilisation would work.
If UNSTABLE is in the config name, when the config is stabilised, users should get a nice message saying "This config is now stable, use this instead" rather than "This config isn't recognised".

If it's gated by the unstable feature, where appropriate, users should get a nice message saying "This has been renamed to ...." or "The possible values have been changed to ....". This one might be more difficult to implement. Might also be weird for a config to silently become stable whilst also introducing breaking changes.

[bugadani]

Might also be weird for a config to silently become stable whilst also introducing breaking changes.

That's a good shout, but we should also generally try our best and not insta-stabilize a breaking change.

[bjoernQ]

I guess we should not rename something in the process of stabilizing it.

Hiding an unstable config option behind the unstable feature sounds good to me.

Given they are only available for unstable I don't see a need to warn about their usage - e.g. we also don't warn the user when calling an unstable function. When they get renamed or removed it's no different from changing any other unstable API item