fix: properly take padding into consideration for selection events on Android

[kirillzyusko]

📜 Description

Correctly handling padding for selection events, especially when it's different (comparing top/bottom).

💡 Motivation and Context

If you apply different paddingTop/paddingBottom, then you will notice, that selection coordinates are not reporting expected values. It happens because of the fact, that we need to take padding into consideration, when we calculate relative text position inside input.

For different gravity we need to use different formulas:

• center: we need to exclude text layout and vertical paddings, then divide by 2 (we'll get a distance that put text in center relative to EditText), and then add paddingTop
• for bottom: we need to exclude layout and bottom padding
• for top we just need to exclude top padding

And after that we need to add lineHeight / 2 (because otherwise caret will be in the middle of the text,

To understand the problem try various combinations of paddingTop=60/paddingBottom=20/textAlignVertical="top|center|bottom" (reverse paddings as well).

You'll see, how it produces different values. With this PR in place we always will get the same relative position (blue box will always follow a carret).

📢 Changelog

Android

• take padding into consideration when we calculate vertical offset (which is based on gravity);
• add lineHeight / 2 to final vertical offset.

🤔 How Has This Been Tested?

Tested on Medium Phone API 35.

📸 Screenshots (if appropriate):

📝 Checklist

• CI successfully passed
• I added new mocks and corresponding unit-tests if library API was changed

[github-actions]

📊 Package size report

Current size	Target Size	Difference
168507 bytes	168453 bytes	54 bytes 📈