fix: ALife graph registry robustness and key_bindings DIK exposure for Lua (CoC)

[ChugunovRoman]

ALife graph registry (alife_graph_registry.cpp)
CoC ends up calling teleport_object from Lua in situations where the NPC is no longer in the graph cell that matches m_tGraphID. The engine then hit CSafeMapIterator::remove with “object not in registry” and died. I made remove look for the id on all graph vertices, and if it’s nowhere, skip the graph remove instead of asserting. Same situation could leave you with a strict level().remove on an empty level registry, so when the graph remove didn’t actually remove anything, the level remove is done with no_assert.

On disconnect I also saw the opposite: add blowing up with “already in registry” when se_monster’s on_unregister (or whatever runs during teardown) tried to register again while the object was still listed. add is now safe in that case: if the same pointer is already in the target vertex we no-op; otherwise we strip that id from every vertex once and then insert.

Refs #2058 (same class of CoC + ALife weirdness).

Key bindings for Lua (key_binding_registrator_script.cpp + key_binding_dik_lua.inl)
AXR’s axr_keybind does key_bindings["DIK_…"] for values coming from config. In OpenXRay those scan codes only lived on DIK_keys, so Lua died with no static 'DIK_NUMPADENTER' in class 'key_bindings'. I mirrored the same value(...) list onto key_bindings via a shared include so we don’t maintain two divergent copies. Also fixed the stray ) in DIK_KBDILLUMTOGGLE’s string while at it.

[Xottab-DUTY]

ALife graph registry (alife_graph_registry.cpp)
CoC ends up calling teleport_object from Lua in situations where the NPC is no longer in the graph cell that matches m_tGraphID. The engine then hit CSafeMapIterator::remove with “object not in registry” and died. I made remove look for the id on all graph vertices, and if it’s nowhere, skip the graph remove instead of asserting. Same situation could leave you with a strict level().remove on an empty level registry, so when the graph remove didn’t actually remove anything, the level remove is done with no_assert.

On disconnect I also saw the opposite: add blowing up with “already in registry” when se_monster’s on_unregister (or whatever runs during teardown) tried to register again while the object was still listed. add is now safe in that case: if the same pointer is already in the target vertex we no-op; otherwise we strip that id from every vertex once and then insert.

Could you describe the problem in Russian? :)

Key bindings for Lua (key_binding_registrator_script.cpp + key_binding_dik_lua.inl)
AXR’s axr_keybind does key_bindings["DIK_…"] for values coming from config. In OpenXRay those scan codes only lived on DIK_keys, so Lua died with no static 'DIK_NUMPADENTER' in class 'key_bindings'. I mirrored the same value(...) list onto key_bindings via a shared include so we don’t maintain two divergent copies. Also fixed the stray ) in DIK_KBDILLUMTOGGLE’s string while at it.

The problem with DIK_ crashes in Lua is due to wrong luabind behaviour and it's bad idea to make workarounds for it in the game code, we should fix luabind directly. So, I don't approve the proposed workaround.