Fix Incorrect Display Bounds Calculation for Linux

[Sohimaster]

This PR resolves an issue in the GetDisplayBounds function on Linux systems where:

    1. Bounds were incorrectly calculated due to improper handling of absolute coordinates.
    2. Displays with non-standard arrangements produced incorrect bounds.

Changes:

    1. Updated GetDisplayBounds to use absolute coordinates based on xinerama data.

Testing:

    1. Verified the fix using multi-monitor setups on Linux.
    2. Confirmed screenshots correctly match individual monitor bounds.

[Sohimaster]

@kbinani Hi! Let's merge the fix if you don't have any questions

[kbinani]

@Sohimaster Thanks for the PR. According to the coordinate section in the README, this library treats the top-left of the primary screen as the origin. Your changes seem to break that design. Please review the README’s coordinate section to ensure consistency with our approach.

[Sohimaster]

@kbinani not really sure what it means but the library wasn't working for me before as it doesn't expect the primary screen to have index different than 0 (as in my setup in the picture)

so when I was taking a screenshot of my primary screen, it would capture the other one instead with an incorrect resolution. As for the other one, it did not capture anything at all. So I did some debugging and found the cause which I fixed in this PR

[Zeeno-atl]

@Sohimaster It means that for this arrangement I have on the screenshot

where eDP is primary screen, I need to screenshot with negative coordinates to get screenshot of the HDMI display.

> xrandr --listmonitors                                                                                                                                                       
Monitors: 2
 0: +*eDP 1920/344x1080/193+1920+722  eDP
 1: +HDMI-1-1 1920/518x1200/324+0+0  HDMI-1-1

To get screenshot of eDP I do area[x,y,w,h] (0,0,1920,1080) whereas to get screenshot of the HDMI I need to get area(-1920,-722,1920,1200). Which is correct behaviour per the definition of the origin (0,0). I do not use the function CaptureDisplay so I can not confirm the functionality.

I believe that in order for your PR to be accepted, you would need to keep the subtraction and you would need to find the "proper" primary display in your case at index [1] I guess if the code is truly malfunctioning. Please post more info, especially something similar to the xrandr --listmonitors output so the author can have insight on what is going on.