Fixed horizontal navigation issue for NavClampRectToVisibleAreaForMoveDir

[zzzyap]

Issue:

• If the value of the column is unclipped and long (such that the center of its rect is past the item on the right column).
  Trying to move left into this column from the column on its right, would ignore this column.
  (Do yell out if this ^ doesn't make any sense)

Changes:

• If the window has columns, clip the rect's horizontal bounds.

[ocornut]

Please provide a screenshot with your problematic layout for reference.
I need to look at this in details as it this may possibly be causing more problems.

(We might also want to bake this info somehow because NavScoreItem() > NavClampRectToVisibleAreaForMoveDir() can be called a lot, we can consider this once the right solution is found).

[zzzyap]

For reference, the code to generate the widget in the following examples:

ImGui::Begin("NavClamp Example");
ImGui::Columns(2);
ImGui::SmallButton("Really really really really really really long text");
ImGui::NextColumn();
ImGui::SmallButton("Short text");
ImGui::NextColumn();
ImGui::End();

---

Using nav with keyboard (Left arrow) without fix, can't move into left column.

---

Using nav with keyboard (Left arrow) with fix, can move into left column.

---

The widget stretched out for reference.

---

Using nav with keyboard (Left arrow) without fix, to demonstrate:

the center of its rect is past the item on the right column

[ocornut]

I thoroughly apologize for not getting on this earlier... I am currently doing a pass at navigation issue and stumbled on this.
I suspect in practice it didn't happen "so much" because code layout clickable contents in table/columns would probably have a tendency to right-align it.

Pushed fix 00d3f92 + Pushed regression test ocornut/imgui_test_engine@c953209

The fix I pushed is slightly different:

• The thing was slightly abstract in term of a "NavIsScrollPushableX" concept which could apply to other items such as a PushWorkRect() API I intend to provide later. I also cached the result and stored it in a hot location as this is a pre-clipping check when a navigation query is running.
• I am doing the clamp earlier (in NavProcessItem()), one of the reason which is not immediately obvious it that the clamp also needs to be done on the "source" scoring rect (generally == current nav location). This isn't making a difference in current version because we currently do scoring_rect.Max.x = scoring_rect.Min.x; in NavUpdateCreateMoveRequest() so the scoring rect is currently a line instead of a rect, but as soon as you revert it to be a rect you need this clamping to be done the same way, otherwise the same bug manifest but with the source item instead of the target candidate item.

Thank you for your patience 🙇

[ocornut]

Amended with eed7b0e : the code in NavClampRectToVisibleAreaForMoveDir() now seems unnecessary.