to the function where all of the others were extracted to from
vout_CreateVars() recently

addresses fixme from 2011: d9dd2df2

during (clean) shutdown the config set, if dirty, is flushed to disk
(in libvlc_InternalCleanup()), so long as --ignore-config is not used.

thus, removing this direct save:

 1) does not stop the changes being saved as they currently are, so long
    as VLC does not crash.
 2) makes things more efficient if the user does also edit and save their
    preferences on first use, since these changes will be flushed in the
    same save action, rather than there being 2+ saves.
 3) removing this direct save means that --ignore-config is actually
    obeyed.

i do not follow the argument in the comment about other plugins changing
items of their own, though this comes from a time when writes had been
modelled in a module-scope way. the config set is primarily a description
of available options, but also holds state, with that state being a
representation of the saved settings file, plus any updates waiting to be
flushed to it. the object variables system is used to capture run time
state, with 'get' requests falling back to config item state when no
specific runtime state is set. changes to the config state, except from
preference interfaces, are very rare, but are made specifically with the
intention to be flushed (saved) to the save file at some point. thus i
don't see the issue with such other-plugin changes being flushed here at
the same time as the qt changes were.

however, as explained above, the best thing is to not perform the save
here, as it is inefficient to do so, and does not obey --ignore-config.
the changes are not important enough to force a write to survive a non-
clean shutdown.

like the hotkey edit table now does

This reverts commit d9b28c03.

The disabling of focus was done due to the design of the dialog
preventing use of the space button in key/sequence assignments
otherwise, as pressing the space bar triggered whichever button
was in focus.

This is now unnecessary with the redesign of this dialog based upon
QKeySequenceEdit, which can hold focus.

this addresses the following bugs/limitations of the existing mechanism
(none of which seem to have entries in trac that i could find):

 1) It was impossible to correctly enter certain simple combinations,
    specifically those involving non-primary key assignments. E.g. on
    my keyboard, to assign '+' requires typing 'Shift+=', but this results
    in 'Shift++'.

    Debugging this issue showed that the QKeyEvent object returns '+' from
    key() and also tells us that the shift modifier was in use. The event
    handler must combine use of modifiers with the key used, otherwise it
    would be impossible to capture sequences like Ctrl+O. Having spent time
    looking at the Qt documentation and trying various things, I cannot
    find any solution that gives us the correct information to get the
    right results. I would expect the key event, if specifying '+' as the
    key in this case, instead of '=', to have 'consumed' the shift modifier
    and thus not report the shift modifier as being in use, but this is
    strangely not so... Is this a bug in Qt? Or, are we supposed to ignore
    the shift modifier unlike the others? Would that work? If so is that
    definitely the only one we should ignore? This requires more (internet)
    research (I was doing this and am typing this up entirely offline).

 2) It was impossible to assign more than one key/sequence to an action.

    Some actions by default have more than one key assigned; this does not
    apply to MacOSX/Windows platforms (the latter just because of an
    unresolved bug in media key handling).

    The edit dialog is limited to capturing and assigning the sequence
    from a single key press event only, which  does not allow for more
    than one sequence to be given.

 3) The edit dialog disables focusing on its buttons.

    This is necessary to support being able to use the space key in key
    or sequence assignment, otherwise the focussed button is triggered
    incorrectly. This is poor UX and an accessibility issue. It is only
    necessary due to the existing design of the dialog, and will not be
    necessary with a control like QKeySequenceEdit.

 4) If a conflict was detected, the dialog would display the given input,
    along with pointing to the (first) action with it already assigned; it
    would allow the user to force a change of assignment, or to supply an
    alternative. It would not however display the name of the action which
    you are attempting to change any longer, which is poor UX.

There were other issues that have already been taken care of, (and maybe
others remaining), but all of these seemed best to cover in one go in a
switch to the QKeySequenceEdit widget. (#3 will be corrected in a follow
up commit).

I expect that the MacOSX GUI suffers from the same flaws, but I'm leaving
that to a Mac dev to deal with.

if the edit dialog detects a conflict, the 'conflicts' property is set to
true along with the dialog being updated to warn the user, offering them
the option of forcing a change in assignment. if they choose to force
assignment then that flag will correctly cause existing use to be cleared.

however, also available to the user is the option of simply entering a
different key/combination to be set, which will trigger a fresh conflict
check, and either this new combination will be accepted, if no conflict,
or the dialog will be updated with new conflict info. in the former case,
the 'conflict' property was left set, thus causing the table to be
pointlessly iterated over to clear existing use, when we know there isn't
any.

this change simply clears the 'conflict' attribute at the start of
performing a conflict check, thus preventing that.

the old solution:
 1) collected a list of all matching items
 2) iterated over all items, for each one checking whether or not it
    was contained within that set

the new solution simply iterates over the items, checking and setting the
hidden property as appropriate as it does so

keep the existing separator (tab) for config defaults and storage, for
compatibility, but swap with comma+space separator when displaying in
Qt GUI control. It is less confusing; matches style of QKeySequenceEdit
control; etc.

i.e. update when user changes field selection combobox

let's start the text with something describing the actual purpose
of the overall control, rather than leaping directly into
instructions on how to use it.

also, let's clarify those instructions a bit.

looks better imo

the addition of multiple key assignments on some platforms like mine makes
the starting width too small, which is annoying

such that every entry in the hotkey table has text for the tooltip giving a
description of hotkey-action purpose

this makes longtext of hotkey actions available to users, helping them to
understand the purpose of the actions listed in the table.

unused since e1c82853

unused since dda157b5

and a couple of other typos spotted while at it

previously the hotkey conflict check did not understand actions which have
more than one key/key-combination (tab separated) assigned, and as such
it allowed keys/key-combinations to be assigned to more than one action in
some cases.

e.g. on Linux systems, the "key-play-pause" action has both "Space" and
"Media Play Pause" keys assigned, but because the string is
"Space\tMedia Play Pause" not "Space" and because the conflict check just
matches against the entire string, the conflict is overlooked if trying to
set "Space" on something else.

This is a regression in conflict detection dating back to
baf3e50b (v2.1 dev).
It then applied to both Linux and Windows, but the changes in
e8668774 during v2.2 dev happened to revert
Windows back to single key mappings, leaving just Linux affected then and
now (assuming that the users do not manually edit their config file to
set multiple bindings).

Note that it is impossible for users to set more than one binding to an
action in the Qt GUI, users can only set them by otherwise editing their
saved settings file.

Note also that this obviously only fixes Qt, the problem likely still
exists in the MacOSX code (which I leave for a mac guy to handle), but
thankfully there are no such dual bindings there by default, so users
won't notice (again, unless they modify their saved settings file directly).

this moves to looping over the table entries directly to find matches,
rather than building a list up front.

the primary purpose of this is not efficiency, it is to support a
significant fix to come in the next commit

enhancing the previous improvement (fix) which ignores the item itself
when checking for conflicts with other actions, this now no longer just
looks at the first result only, but goes through the list of conflicts.

remember, there is no reason why the starting state on loading this control
could not already contain conflicts; and the first could always be the
item being edited itself, so don't just look at the first conflict, check
them all.

and use it

as just explained in removing the incorrect tooltip from the hotkey table's
label, the item pointer provided to the constructor of this control/widget
is that of a single hotkey config item (used in the advanced view this is
that of the first hotkey config item encountered, then all others are
ignored; for simple view the "key-play" option is arbitrary used). the
control contrastingly is used to edit the whole set of hotkey items.

the point in passing along an item pointer was that the base control class
requires one (all other controls target a single config item); it makes
absolutely no sense for this one though. this removes the param, and
passes along null to the base control constructor.

the item pointer provided to the constructor is that of a single hotkey
config item (used in the advanced view this is that of the first hotkey
config item encountered, then all others are ignored; for simple view the
"key-play" option is arbitrary used).

using the longtext from this item in a tooltip on the label for the entire
hotkey table makes zero sense, so let's remove it.

previously, if you tried to set a hotkey to use the same key as it already
was set to, it would detect a conflict in that the selected key was already
in use, failing to recognise though that it was conflicting with itself.

this passes the tree item pointer along to the dialog so that it can be
smarter, and fixes the problem