Tag API leaking Windows OLE methods/fields as non-api

[HannesWell]

Instead of just suppressing the resource-leakage warnings, tag the methods/fields that leak non-API types as non-api themself.
This is an alternative solution to #1106 (comment) to
get rid of the resource-leakage warnings in the Windows OLE part of SWT.
I think that's the more natural way to resolve this issue and has the advantage that we only temporarily have to add filters to suppress the error that a method/field became non-api.

@iloveeclipse or anybody else, what do you think about that?

[github-actions]

Test Results

  110 files   -  8    110 suites   - 8   10m 47s ⏱️ - 5m 35s
4 594 tests  - 56  4 386 ✅  - 247  208 💤 +191  0 ❌ ±0 
  274 runs   - 56    273 ✅  -  53    1 💤  -   3  0 ❌ ±0 

Results for commit 3362695. ± Comparison against base commit 079d2a9.

This pull request removes 56 tests.

AllWin32Tests ImageWin32Tests ‑ testDisposeDrawnImageBeforeRequestingTargetForOtherZoom
AllWin32Tests ImageWin32Tests ‑ testDrawImageAtDifferentZooms(boolean)[1] true
AllWin32Tests ImageWin32Tests ‑ testDrawImageAtDifferentZooms(boolean)[2] false
AllWin32Tests ImageWin32Tests ‑ testImageDataForDifferentFractionalZoomsShouldBeDifferent
AllWin32Tests ImageWin32Tests ‑ testImageShouldHaveDimesionAsPerZoomLevel
AllWin32Tests ImageWin32Tests ‑ testRetrieveImageDataAtDifferentZooms(boolean)[1] true
AllWin32Tests ImageWin32Tests ‑ testRetrieveImageDataAtDifferentZooms(boolean)[2] false
AllWin32Tests ImageWin32Tests ‑ test_getImageData_fromCopiedImage
AllWin32Tests ImageWin32Tests ‑ test_getImageData_fromImageForImageDataFromImage
AllWin32Tests TestTreeColumn ‑ test_ColumnOrder
…

This pull request skips 194 tests.

org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser ‑ test_Constructor_multipleInstantiationsInDifferentThreads
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser_IE ‑ test_BrowserFunction_callback
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser_IE ‑ test_BrowserFunction_callback_afterPageReload
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser_IE ‑ test_BrowserFunction_callback_stackedCalls
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser_IE ‑ test_BrowserFunction_callback_with_String
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser_IE ‑ test_BrowserFunction_callback_with_boolean
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser_IE ‑ test_BrowserFunction_callback_with_integer
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser_IE ‑ test_BrowserFunction_callback_with_javaReturningInt
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser_IE ‑ test_BrowserFunction_callback_with_javaReturningString
org.eclipse.swt.tests.junit.Test_org_eclipse_swt_browser_Browser_IE ‑ test_BrowserFunction_callback_with_multipleValues
…

♻️ This comment has been updated with latest results.

[HannesWell]

Does anybody have an opinion on this?

[akurtakov]

@HeikoKlare What do you think of this one?

[HeikoKlare]

Sounds reasonable to me. I fully agree with:

I think that's the more natural way to resolve this issue and has the advantage that we only temporarily have to add filters to suppress the error that a method/field became non-api.

It will allow us to get rid of most of the API filter for the Windows fragments, which would be really great. And I don't see any risk either, because if someone unexpectedly relies on those methods being API, they will still exist and will still be referencable.

The current failures seem to be caused by the temporary filters for the API removals missing in the aarch64 fragment. @HannesWell do you want to add them so that we may even merge this for the upcoming release and can get rid of all the filters already in December?