Caret scaling implemetation improvement on StyledText DPI change

[amartya4256]

This PR improves the way carets of StyledText is scaled on DPI change event by utilizing APIs instead of win32 specific static methods.

contributes to #62 and #128

Depends on #2469 and #2471

[github-actions]

Test Results

   485 files   -    61     485 suites   - 61   25m 28s ⏱️ - 6m 4s
 4 335 tests  -    91   4 304 ✅  -   105   12 💤  -  5  6 ❌ +6  13 🔥 +13 
13 075 runs   - 3 675  12 940 ✅  - 3 683  116 💤  - 11  6 ❌ +6  13 🔥 +13 

For more details on these failures and errors, see this check.

Results for commit 396a9dc. ± Comparison against base commit f6de513.

This pull request removes 91 tests.

AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_dollarSign
AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_emptyString
AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_letterA
AllGTKTests Test_GtkConverter ‑ test_HeuristicASCII_letters
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16LE_null
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_AsciiLetters
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_Asciiletter
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_LotsOfLetters
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_letter
AllGTKTests Test_GtkConverter ‑ test_HeuristicUTF16_letters
…

♻️ This comment has been updated with latest results.

[HeikoKlare]

Can you explain what changes when replacing the calls to SystemParametersInfo to SystemParametersInfoForDpi? I.e., what will be different both in terms of user experience and/or in terms of internal functionality when not doing the changes to the DPI change handling as well.

In addition, should be split this change up into replacing the existing calls and adapting the DPI change handling? I would also appreciate an explanation of why the method calls inside updateAndRefreshCarets() have to be moved to understand what happens there.

[amartya4256]

Can you explain what changes when replacing the calls to SystemParametersInfo to SystemParametersInfoForDpi? I.e., what will be different both in terms of user experience and/or in terms of internal functionality when not doing the changes to the DPI change handling as well.

In addition, should be split this change up into replacing the existing calls and adapting the DPI change handling? I would also appreciate an explanation of why the method calls inside updateAndRefreshCarets() have to be moved to understand what happens there.

It is already split. It depends on #2471. The new API is used to retrieve the system's preferred width for the cursor. Earlier, it used the system DPI aware value, which would always return the value for the first monitor on which the App was started on, could lead to the cursors looking too think or too wide. This kind of behaviour is although not always visible as mostly, all the monitors have the same width. With Per-monitor DPI aware API, we make sure that the retrieved width is specific to the current monitor's preference and doesn't appear too think or too flat.