bluez5: Do not suspend on no -> unknown profile transitions

In case a transport is currently disconnected and transitions to
idle, that should not count as a "remote hang up" event.

Signed-off-by: David Henningsson <david.henningsson@canonical.com>
card-restore: Fix profile restoring with bluetooth

The bluetooth card is created when the first profile becomes
available, which means that the card may have profiles that are not
available when the card is initialized. If module-card-restore tries
to restore such profile, that will fail, and the card will be
initialized with the "off" profile active.

This patch modifies module-card-restore so that if follows the profile
availability status, and when the saved profile becomes available, it
is activated. Additionally, module-card-restore is modified so that it
doesn't even try to restore unavailable profiles, when the necessary
information is available. In practice there are two existing places
where the profile is restored, and only one of those contexts has the
necessary information available. Unfortunately, it's the more
important context (card creation) where the information is not
available. This means that module-card-restore will set the initial
profile of a new card even if the profile is unavailable, and this
will cause an ugly warning in the log, even though there's nothing
abnormal happening.

BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=87081