Introduce simple API to save ImageData to file and support '.jpg' extension

[HannesWell]

Currently it's quite cumbersome to save ImageData into a file. screenshot from a Control or a Display. This proposes a convenience API to simplify this task.

This also complements the ImageData.load(Path) method introduced in

• Replace and deprecate Image creating methods accepting Strings as file-system paths #1767

It becomes also very simple to take and save a screenshot together with

• Introduce simple API to take a screenshot #2104, .

[github-actions]

Test Results

   545 files  + 6     545 suites  +6   29m 47s ⏱️ - 1m 1s
 4 376 tests +37   4 358 ✅ +35   18 💤 +3  0 ❌  - 1 
16 643 runs  +37  16 503 ✅ +35  140 💤 +3  0 ❌  - 1 

Results for commit b724b57. ± Comparison against base commit d1859ce.

[laeubi]

I don't think we should clutter the ImageData class more can't we use ImageLoader(sic) for this that already is used internally anyways?

[HannesWell]

Currently there are only convenience methods to load ImageData. Right now it's a constructor copying the first element of an ImageData-array into itself, but it will become just ImageData.load() with #1767. Currently there is no (simple) way to save an Image(Data) to a file. So I think this closes a gap in the Image(Data) API and I don't consider this as cluttering the API.
If we move this somewhere else then we can also just leave it as it, because many wont discover that way then anyways.

That one has to write an article about how to simply write an image to a file, is IMO an indication that the API is too complicated:
https://www.eclipse.org/articles/Article-SWT-images/graphics-resources.html#Saving%20Images

Of course there are cases where one still needs an ImageLoader, but the simple cases should be simple.

[laeubi]

I don't think that adding methods to ImageData is a good idea, this should only be a data carrier and is not a general purpose place to put continence methods.

So why cant this static methods live in ImageLoader (or we can have a new ImageWriter)?

[akurtakov]

Would you please split the *.jpg support in its own PR so it can be merged now?

[akurtakov]

Is there still interest in this one or it should be closed?