core: services: wifi: add support for WPA-Enterprise

### Current behaviour

There is currently only support for WPA-Personal connections (with an SSID and an optional password), which means WPA-Enterprise networks (which also require an "identity"/username) cannot be connected to, which is annoying for users who only have access to such a network, and also prevents using more secure wifi connections.

Raised in [this forum post](https://discuss.bluerobotics.com/t/unable-to-log-into-public-wi-fi-networks-on-blueos/14545), about eduroam.

### Expected or desired behaviour

If it's somehow possible to detect the network type then it would be nice to just include a username field in addition to the existing password one, and then auto-fill the relevant network parameters. Assuming that's not possible, the most intuitive interface I can think of would be having an "advanced settings" dropdown that provides access to things like the username, key management, etc.

From a quick look online I believe the password should be hashable by [the process described here](https://unix.stackexchange.com/a/278948), but I'm not certain about that. If the password is not hashable for this connection approach then we should either disallow using a password for such a connection (i.e. only allow them for unsecured networks), or at minimum provide a warning to the user, because enterprise networks often use single sign-on structures whereby a person's username and password is shared across various services, including things like wifi access, email access, and intranet access. This is particularly relevant because a person logging in to an enterprise account is likely not using a personal vehicle, in which case other members of their team / faculty may get access to their login credentials when using the vehicle later.

Ideally we would also be able to re-prompt for credentials at some (user-specified?) frequency, but I'm not sure how hard that would be to set up or enforce. Perhaps it could be achieved by some settings that BlueOS checks on startup and triggers a wipe of any enterprise credentials if the timeout has passed, or alternatively it could just wipe those credentials whenever it starts up (and potentially also as part of the normal container shutdown process?), to enforce a minimum of one enterprise login per BlueOS restart.

It's worth noting that enterprise organisations may not want Raspberry Pis connected to their networks without some explicit approval, and even with a hashed password it's not super secure - a more recommended approach for tethered connections would be to [pass internet through the tether](https://github.com/bluerobotics/BlueOS-docker/issues/1444), which we can potentially even suggest as an alternative when someone opens the advanced wifi connection settings, as something of an "are you sure?".

### Prerequisites

- [X] I have checked to make sure that a similar request has not already been filed or fixed.

Start by tracing the existing WPA-Personal connection flow and its network-configuration entry point. Confirm how WPA-Enterprise credentials, key management, password storage, and credential expiration should work before changing the interface. Done means an approved, secure connection path for enterprise networks with clear credential handling and appropriate warnings or alternatives.

Written by the indexing model from the issue text.