[Cocoa] Replace deprecated NSProgressIndicatorPreferredThickness

[HeikoKlare]

NSProgressIndicatorPreferredThickness is deprecated since macOS 10.14. The deprecation message in the SDK header (NSProgressIndicator.h) prescribes the replacement:

These constants do not accurately represent the geometry of NSProgressIndicator. Use controlSize and sizeToFit instead.

This change adds a binding for NSProgressIndicator#sizeToFit and uses it in ProgressBar#computeSize to determine the default thickness, restoring the original frame afterwards since computeSize must not have side effects on the widget's bounds. The header documents exactly the semantics this relies on:

For the spinning style, it will size the view to its default size. For the bar style, the height will be set to the recommended height.

SWT always uses the bar style and never changes the indicator's controlSize (it stays at the default NSControlSizeRegular), so sizeToFit yields the recommended thickness for that control size.

Note that this changes the default thickness of a ProgressBar from the hardcoded 14px to the value AppKit actually reports for the current system (18px on macOS 15): the deprecated constant was a stale Aqua-era value that, per the deprecation message, "does not accurately represent the geometry" of the rendered indicator.

How to test

Open the ProgressBar tab of the SWT ControlExample (org.eclipse.swt.examples.controlexample.ControlExample). In the Size group, the default Preferred setting sizes the bars via computeSize, i.e., the changed code path. With this change, the horizontal progress bar becomes 18px instead of 14px tall (the vertical one correspondingly wider), matching the geometry AppKit recommends.

Before:

After:

Contributes to #3214

🤖 Generated with Claude Code

[github-actions]

Test Results (macos)

   64 files  ±0     64 suites  ±0   9m 1s ⏱️ + 2m 56s
4 584 tests ±0  4 335 ✅ ±0  249 💤 ±0  0 ❌ ±0 
2 226 runs  ±0  2 160 ✅ ±0   66 💤 ±0  0 ❌ ±0 

Results for commit 90cb2fd. ± Comparison against base commit 2765985.

♻️ This comment has been updated with latest results.

[Phillipus]

I thought you couldn't add code to NS* classes (NSProgressIndicator.java) as they are auto-generated by the MacGenerator tool?

#1081 (comment)

[HeikoKlare]

I thought you couldn't add code to NS* classes (NSProgressIndicator.java) as they are auto-generated by the MacGenerator tool?

That's a very good hint, thank you. I have to admit that I was not aware of the exact purpose of that tool. I just executed it and turns out that several changes performed in the recent past (by me and others) did not take that into account properly, such that running the MacGenerator now produces some unexpected result. I will try to take a look what needs to be done to make the current state consistent to the MacGenerator again. And we definitely have to update the Agents.md with that information to ensure that agents to not produce such changes.

[Phillipus]

Actually I missed that you also made changes in AppKitFull.bridgesupport.extras in this commit so maybe you already did the right thing?

[HeikoKlare]

Might be. But since the agent did definitely not use the MacGenerator tool, we should not further process this before doing so and verifying that the change is sound.
I propose to first clean up the current state (such that executing the MacGenerator does not produce any changes) before proceeding with this one (thus marking it as draft again).