Make classes not depend on the implicit GImGui context (#6199, #5856, #6199): ImGuiIO

This commit is a preparation toward adding ImGui apis with explicit context
and making ImGui applications being able to use multiple context at the same time
whatever their concurrency model.

About ImGuiIO:
- ImGuiIO depends on ImGuiContext because some of its method want to event to `g.InputEventQueue`.
- To make ImGuiIO aware of the context to use, context which creates the ImGuiIO is given as argument of ImGuiIO constructor.
- The assert `IM_ASSERT(&g.IO == this && "Can only add events to current context.")` has been removed since it does not make sense anymore

NOTE: ImGuiIO could be completely independent of ImGuiContext if the InputEventQueue was moved from ImGuiContext to ImGuiIO, but since
ImGuiIO is a public class it would expose InputEvent type. Solving this problem is out of the current scope, but it is interesting to notice.

docs/CHANGELOG.txt

@@ -54,6 +54,7 @@ Other changes:
 - Nav: Fixed an issue with Gamepad navigation when the movement lead to a scroll and
   frame time > repeat rate. Triggering a new move request on the same frame as a move
   result lead to an incorrect calculation and loss of navigation id. (#6171)
+- IO: Lifted constraint to call io.AddEventXXX functions from current context. (#4921, #5856, #6199)
 - Drag and Drop: Fixed handling of overlapping targets when smaller one is submitted
   before and can accept the same data type. (#6183).
 - Drag and Drop: Clear drag and drop state as soon as delivery is accepted in order to