module: LVGL: Improve support for hardware display rotation

[faxe1008]

Originally brought up within #73474 this PR tries to improve the support for hardware based display rotation during runtime.

Since in the past few weeks quite a few bugfixes in regards to pointer input device handling were merged it would be useful to have them properly unit tested.

Test output:

===================================================================
START - test_no_rotation
        Expected: x:20 y:150
        Press:    x:20 y:150
        Release:  x:20 y:150
 PASS - test_no_rotation in 0.001 seconds
===================================================================
START - test_rotation_180
        Expected: x:300 y:90
        Press:    x:300 y:90
        Release:  x:300 y:90
 PASS - test_rotation_180 in 0.001 seconds
===================================================================
START - test_rotation_270
        Expected: x:150 y:300
        Press:    x:150 y:300
        Release:  x:150 y:300
 PASS - test_rotation_270 in 0.001 seconds
===================================================================
START - test_rotation_90
        Expected: x:90 y:20
        Press:    x:90 y:20
        Release:  x:90 y:20
 PASS - test_rotation_90 in 0.001 seconds
===================================================================

[faxe1008]

Add a comment that this should not be called while rendering is in progress.

[faxe1008]

Changing this from draft state to review to get some more feedback and hopefully quite a few other pair of eyes on this since the coordinate conversion code has been tricky to handle.

Added @ioannis-karachalios as a reviewer because of #73407

[Snevzor]

Perhaps the test can be expanded to take into account correct rotation initialisation based on the various rotation dts values as well? Like: looping through all dts values and then checking if the input values match. That way the updated LVGL init code is also tested.

[faxe1008]

@Snevzor neat idea but I fear that this would mean that I'd have to add an overlay on for each rotation and do some messy things with skipping tests I pressume. Could be wrong though :^).

Btw I added a DNM label for now since I want to clarify the discussion around #73360 first.

[github-actions]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

[danieldegrasse]

@faxe1008 apologies for the necromancy here- It seems like this PR is the start of what we would need to standardize how rotation works within Zephyr (IE if the display driver should be swapping x/y parameters when rotated, or if the consumer of the display API should be handling this)

Do you still want to move this forwards? It seems like we'd need this, as well as changes to the gc9x01x and ili9xxx drivers to align them with the remainder of the codebase

[Snevzor]

@faxe1008 please let me know if you need some assistance, I definitely want to help where possible.

[faxe1008]

Heyhey @danieldegrasse and @Snevzor yes eventually I want to continue working on that issue, either by contributing or reviewing, if someone feels inspired to take this up in the meantime. I want to first finish up the update of the module its self since this has been sitting on my plate quite some time now before moving on to other issues. Can you maybe spare some time to look at #81263?