[Build] Remove SWT library version information built into binaries

[HannesWell]

This removes all native/library version information that is currently built into the native binaries of SWT.
Consequently the library-version information is only captured in the name of the native binary files and in the 'Library' java class.
The previously built-in information is not used anywhere in SWT.

This allows to just rename the binary files in case just the library version has changed without a change in the native sources. This happens for example if only the native sources for another platform are changed.

[github-actions]

Test Results

   545 files  + 6     545 suites  +6   27m 35s ⏱️ - 2m 24s
 4 367 tests +37   4 355 ✅ +35   12 💤 +3  0 ❌  - 1 
16 616 runs  +37  16 512 ✅ +35  104 💤 +3  0 ❌  - 1 

Results for commit d0aacb3. ± Comparison against base commit 22e8829.

♻️ This comment has been updated with latest results.

[HannesWell]

I have investigated the outcome of this change a bit further and noticed that the initially removed version.txt file is not relevant for the content of the native binaries and therefore restored it.
Technically it could be removed, but when this was done five years ago in Bug 548535 it was argued that it could help users to identify the library version easier.
If removal should be attempted again, it should be done in another PR.

For Linux and Mac this PR effectively changes nothing. It just removes some declared compiler constant that define library-version information that is not referenced.

The only real change is for the native-library binaries for Windows as this removes the file-version information from the metadata that is e.g. displayed in the Details section of the Properties-Dialog in the Windows file-explorer (previously it was 4,969,6,0):

But as this simplifies releng tasks and moreover allows to make the (native) build more robust and to lower future growth of Git large-file storage occupation via #1940 I think this is worth it.

[HeikoKlare]

The idea sounds good to me. I never had a need fpr the DLL version metadata, so I am fine with removing them. I second your assessment of favoring robust builds and less growing files over the usually unused metadata.

Only scenario I in which I would see a need for them is if they would be installed to Windows and a matching version is searched for while dynamically linking against the SWT library. But I don't think this is a relevant scenario that has ever been used (I am not even sure if it's possible the way I imagine it).

[HannesWell]

Only scenario I in which I would see a need for them is if they would be installed to Windows and a matching version is searched for while dynamically linking against the SWT library. But I don't think this is a relevant scenario that has ever been used (I am not even sure if it's possible the way I imagine it).

You mean another (native) application is compiled against the SWT native libraries? I don't think that this is a use-case that was ever considered for SWT. At least I'm not aware that for the binaries any promises regarding API/ABI-stability are made.