icera: don't reset connection if cancelled, wait to get connected before

If we are requested to cancel the connection, we first need to wait for the
connection attempt to finish before issuing the disconnect command, as otherwise
the modem just returns an error saying that it cannot perform the operation and
at the end we end up with the modem connected but ModemManager thinking that it
isn't.

Tries to fix https://bugzilla.gnome.org/show_bug.cgi?id=685578
option,hso: don't reset connection if cancelled, wait to get connected before

If we are requested to cancel the connection, we first need to wait for the
connection attempt to finish before issuing the disconnect command, as otherwise
the modem just returns an error saying that it cannot perform the operation and
at the end we end up with the modem connected but ModemManager thinking that it
isn't.
iface-modem: new helper method to wait until a final state is reached
iface-modem-simple: avoid intermediate states

If the modem is currently disabling, we need to wait to get fully disabled
before starting with the new connection sequence.

If the modem is currently disconnecting, we need to wait to get fully
disconnected before starting with the new connection sequence.
iface-modem: ignore bearer related state changes if disabling or enabling
iface-modem: ignore registration-related state changes if enabling or disabling
iface-modem: when transitioning to ENABLED check registration-specific states
iface-modem,broadband-modem: update 'disabling->disabled' transition logic

It is not the Modem interface the one notifying about the 'disabling->disabled'
transition, it's the BroadbandModem directly doing it, covering all the
disabling sequences of all the interfaces.
iface-modem,broadband-modem: update 'enabling->enabled transition logic

It is not the Modem interface the one notifying about the 'enabling->enabled'
transition, it's the BroadbandModem directly doing it, covering all the enabling
sequences of all the interfaces.
plugin-manager,plugin: improve logging

Logging which are the reasons for a plugin to filter a given port really help
when trying to debug user issues. Some other general logging improvements also
done.
plugin: avoid unneeded vendor/product AT probing if already passed USB ID filter

Don't require vendor/product string probing if the plugin already had
vendor/product ID filters and we actually passed those.
plugin-manager: use dispose() as we're holding plugin objects
plugin-manager,plugin: run pre-probing filters early

For each port, we will construct the list of plugins to test with. In that list
we will include those plugins which are likely to handle a given port, so we
will skip all those which aren't.

To see if a plugin is likely or not, we will run the pre-probing filters before
adding them to the list, with the new `mm_plugin_discard_port_early()'. This
method will return one of these hints:

 * UNSUPPORTED: The plugin will not be able to handle this port.
 * MAYBE: The plugin may handle this port.
 * LIKELY: The plugin may (very likely) handle this port.
 * SUPPORTED: If any plugin should support the port, this is it.

Plugins reported to be 'likely' supporting the port will be probed before the
ones reported just as 'maybe'.

If a plugin reports 'supported' only that one and the fallback generic ones will
be tried.
huawei: reset ignored unsolicited message handlers only once
huawei: ignore '^STIN' unsolicited messages
core,log: include logging from the 'Qmi' log domain

Sync with libqmi:

commit 2835a53732fdae32478dd954a9ee3fa8afd93cab
Author: Aleksander Morgado <aleksander@lanedo.com>
Date:   Tue Oct 30 15:02:24 2012 +0100

    libqmi-glib: define library G_LOG_DOMAIN