patch 9.1.1247: fragile setup to get (preferred) keys from key_name_entry

patch 9.1.1247: fragile setup to get (preferred) keys from key_name_entry

Problem:  fragile setup to get (preferred) keys from key_name_entry
          (after v9.1.1179)
Solution: refactor the code further, fix a bug with "pref_name" key
          entry introduced in v9.1.1180 (Yee Cheng Chin)

The optimization introduced for using bsearch() with key_name_entry
in #16788 was fragile as it required synchronizing a non-obvious index
(e.g. IDX_KEYNAME_SWU) with the array that could be accidentally changed
by any one adding a key to it. Furthermore, the "pref_name" that was
introduced in that change was unnecessary, and in fact introduced a bug,
as we don't always want to use the canonical name.

The bug is triggered when the user triggers auto-complete using a
keycode, such as `:set <Scroll<Tab>`. The bug would end up showing two
copies of `<ScrollWheelUp>` because both entries end up using the
canonical name.

In this change, remove `pref_name`, and simply use a boolean to track
whether an entry is an alt name or not and modify logic to respect that.

Add test to make sure auto-complete works with alt names

closes: #16987

Signed-off-by: Yee Cheng Chin <ychin.git@gmail.com>
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>