Use more predictable units for offset positions

[Andarist]

@dmtrKovalenko has mentioned that the used coordinate system is not intuitive to Cypress users. I partially agree with that - I think though that the internal coordinate system is mostly hidden from users and they don't have to care about it that much because cypress-real-events is taking care of the heavy-lifting and computes the screen positions of AUT elements.
#198 (comment)

I think though that there is one thing that could be done to make interacting with this library more intuitive and preditable

Currently, if we do smth like:

cy.get('div').realClick({ position: {  x: 5, y: 5 } })

then the computed position will use { x: 5, y: 5 } as a screen offset of the element's position. I don't think this is what users expect though, for the majority of use cases. This is especially less-than-ideal as the final position is depending on the screen size and can vary based on the whole window being resized or devtools being open etc

I propose to redefine what this offset means - IMHO this should be an offset from the el.getBoundingClientRect(). That way we'd end up with more consistent results, independent from the root viewport size.

The change should be pretty trivial (but breaking!) - we'd have to essentially shift the logic from getPositionedCoordinates to getElementPositionXY (the latter should probably be renamed in the process).

[dmtrKovalenko]

I agree with that but I do actually aware of breaking changes. I think that any “plug-in” should avoid breaking changes as much as possible.

So we can wait for somebody to actually get really mad because of this or some other breaking changes to group them together.

[Andarist]

Can I count as somebody who got really mad because of this? 😅 It really makes writing some tests quite cumbersome.

For instance, I need to write a test that clicks close to the right side of an element. The problem is that for some reason position: 'right' doesn't work because sometimes I end up with a very minor px difference and the browser "responds" with a click on the background element. It's like I'm hitting very close to the "edge value" in the hit target algorithm. To fix this kind of stuff I would grab the element, calculate its width and just click on something like x: el.width - 5. The problem is that this doesn't work as expected because where the click will actually be dispatched depends on the window size and thus the test written like that is not reliable. However, it would be reliable if only those offsets would be reliable - if they would be expressed in the in-app values.