Split wifi.radio Station and Access Point methods and properties into separate objects

[anecdata]

The question arose in a recent wifi PR whether we should split station and AP into separate objects. radio is getting heavy, with a high count of methods and properties, and a long-running naming issue to distinguish station vs AP. For example, get_ap_info() is for station, but the AP things generally have an _ap suffix. Internal variables sometimes use an ap_ prefix and sometimes an _ap suffix.

wifi.radio.hostname affects both station and AP, though it could easily be split.

wifi.radio.enabled affects both station and AP. The ability to enable and disable wifi completely independent of starting or stopping station or AP can be pretty powerful (current CYW43 limitations aside), I don't think we want to mess that up.

There may be other considerations or side effects.

[anecdata]

Two options come to mind:

(1) Create wifi.radio.ap. for all of the AP-specific functions, and since this is breaking for AP, we could also use the opportunity to simplify those API names (remove _ap). Leave station functions at the wifi.radio. level.

(2) Create wifi.radio.ap. and wifi.radio.station.. Functions common to both (e.g., wifi.radio.enabled) stay at the wifi.radio. level. This may be more intuitive, but breaks everything (user code, examples, guides, etc.).

[bill88t]

Perhaps it could also be a bit simplier like: wifi.radio for management (mac, enabled, txpower, ...), wifi.station and wifi.ap. Following the iwd logic a bit. This way most properties could be identical between the two.

It could be something for 10.x..