handle sticky card profiles

Another attempt to fix HDMI profiles resurrected after xset dpms force off or turning off the display. This is a follow-up to discussion on irc.

[23:48:52] <@gchini> Ford_Prefect, i-garrison: Should we set some disabled_by_user flag for a card when the card profile is manually set to off? I was just looking at !354, which might cause similar issues as in #950
[23:56:28] <Ford_Prefect> gchini: hmm, maybe -- are you thinking that if a profile is manually disabled, we don't allow any automatic logic to switch away from off?
[23:57:00] <@gchini> exactly
[23:57:16] <@gchini> then you could only switch away manually
[23:57:38] <Ford_Prefect> makes sense, and I guess we need to persist that as well

What is done:

• renamed card->save_profile flag to card->profile_is_user_choice for it already tracks if it was user selected profile
• this flag added to card-database, updated version 5 structure
• try_to_switch_profile and card_profile_available_hook_callback stick to user choice
• EDIT: profile_is_user_choice card flag now renamed to profile_is_sticky

Works for me in simple test and should handle #950 (closed) case well, but some work is left to do.

What needs to be done:

• For v15: add pacmd/client (pavucontrol and gnome/kde) support for switching between auto switching and sticking to user choice - done, pavucontrol!52 (closed)
• For v14.1 card-database still needs to be changed, but maybe pacmd/client interface can be preserved as is. One way to do it is to replicate "auto" profile variants like this for UIs
  • profiles "off" and "output:hdmi-stereo" are user choice
  • profiles "off [auto]" and "output:hdmi-stereo [auto]" would reset internal user choice flag
  • user can toggle sticky user choice flag by switching between "XXX" and "XXX [auto]" profile variants
• see if bluetooth modules need the same treatment