Profile management APIs

This MR introduces the suggested API for profile management, initially drafting a minimum set of things to support:

• Listing stored profiles.
• Updating/deleting stored profiles.
• Setting up connections with stored profiles.

The API is based on the discussions at !179 (closed).

The profiles are listed with a new List() method, and it is assumed that the implementation of the method for the different protocols/modems will reload the list each time the method is called. There should be no cached list of profiles inside the daemon.

There is a Updated() signal that may be used to notify when network updates happen on the profiles, e.g. via OTA, and this is also a "best effort", i.e. there is no guarantee at all that this signal will be usable in all protocols/modems.

There is no new method to connect the modem using a profile. Instead, the already existing Modem.CreateBearer() and Simple.Connect() are implicitly updated to support a new profile-id setting that allows the user to select a given profile to connect. When such method is used, the created bearer object is bound to the profile with the given ID (i.e. if the bearer is disconnected, then the profile is updated, and then the bearer is reconnected, the new connection would use the newly updated profile).

It is guaranteed that if the user uses exclusively this new profile management API, the existing profiles won't be implicitly changed by ModemManager during runtime. That is not guaranteed if the user uses the new profile management API sometimes and sometimes it uses e.g. Simple.Connect() without profile-id. I think users should either use it always, or never. It's really a suggestion, because we know List() always reloads on-the-fly the available list, so even if the profiles were changed implicitly during a connection attempt, re-running List() again would give us the most up to date list.

A new apn-type setting is also introduced, as this is something we can use in MBIM and QMI modems, and is really useful to define how the profiles work and what use they have.

In general, I've tried to document things that I think may happen, following some of the comments from the old MR. I think that the key is to have the minimum number of API updates required to have the logic working, and then we can improve them removing limitations or whatever. E.g. the profile management API could be used really to updated the initial EPS bearer settings, but that would collide with SetInitialEpsBearerSettings() so for now, we would allow only the latter, as that implementation already takes care of setting the modem in low-power mode before attempting the change, something that we would not require for other types of profiles in the profile management API.

@vpalatin @ejcaruso @andrewlassalle @jessy.diamondman your comments would be really appreciated.