Expose mod input handlers for better integration between mods

[Supremist]

Allow mods to:

• Get name list of other installed mods
• Get info about input handlers, registered for other mods
• Call input handlers from lua, as if user presses an input key
• Split responsibilities: mods will delegate input management to other specific mods

Current CET implementation of Input & Hotkey functionality provides a good default for mods. But it ignores the game context in which the key was pressed. That means, if the key is bound in CET then it must be unbound in game. That is ok, but with enough mods users will run out of keys they can comfortably press.

My proposal is to allow input mods to monitor in game context and invoke other mods key bindings depending on context. So a single key can do different action, when the player is in a vehicle or while sprinting, for example.
Of course each keybind should be EITHER bound in CET OR managed by separate input mod.

[WSSDude]

I need to take more closer look at this, these are just some quick remarks.

[WSSDude]

I added an extra comment and edited some for better clarity (you won't see changes from email, so check them in the PR please)

[Supremist]

Also, I have to emphasize, that now this PR introduce a braking change in the GetMod function. Just reiterating, to be clear.

[Supremist]

I’m sorry to see my PR gets reverted. Can I help to improve it?
Possible solutions:

1. Introduce new function and do not introduce a breaking change in the existing function (as it was implemented before the review)
2. Merge to different branch with breaking changes and release it later after deprecating the current branch (I don’t really like it, as it is too slow and forcing for other mod authors)
3. Introduce an API version and bind mod to different APIs depending on what version the mod requests. (I like it the most, but it is more work)

[WSSDude]

Apparently, more mods used GetMod than I expected... So new functions which do that would be better probably, GetModContext+GetModContexts probably.

GetMod could be wired to GetModContext and return rootObject to not break former bindings.

[WSSDude]

This was only reason this was reverted, no other really... If it was some separate function in the end, it would be fine.

[maximegmd]

Yes it's pretty much keeping API compatibility, if you implement the suggestions from wssdude, we will merge it again, just didn't have time to make those changes when everyone was complaining it broke mods ^^