Fix and document native build commands for all platforms

[vogella]

Replace broken antrun:run@build-native-binaries command with the correct mvn clean install invocation, quote the -Dnative parameter, and add concise per-platform examples to both AGENTS.md and README.md.

[HannesWell]

I have to say that that this change is IMHO not a net improvement.
Please see my comments below.
Furthermore I'd appropriate if you would give others more time for a review or at leats tag those whose recent work you continue.

[HannesWell]

Suggested change

	mvn clean install
	mvn clean verify

Installing is IMO not the thing we should recommend by default, since it's modifing the user-wide Maven cache. And that's probably not always wanted.
Whoever wants to to that, can change the command accordingly.

For the AGENTS.md file this might not be that important, but we deficiently shouldn't do that in the README.

[HannesWell]

The content should not be here, but instead this paragraph should reference https://github.com/eclipse-platform/eclipse.platform.swt/tree/master/bundles/org.eclipse.swt#building-and-testing-locally.

The commands are implemented in the launch configuration mentioned there.
Therefore I don't know if we should replicate this again, but if you think it should be replicated, there would be the best place.

[HannesWell]

The following commands are not bash specific, you can also run them in a Windows CMD or Powershell.

[HannesWell]

The commands now do something almost completely different and they don't match the section topic anymore.
Furthermore if the abstract syntax is to hard to understand, I suggest to add one specific example instead of just listing specificly only a subset of the supported/targeted platforms.

[merks]

I think this is an example of standing in front of oncoming freeway traffic. There's just so much pushed through so rapidly there’s not enough capacity for adequate review.

[vogella]

Absolutely ok for me if you revert that change. It took me a longer time to figure out how to compile the win natives but I have documented that for me and I'm fine if you restore the original content.

[HannesWell]

Absolutely ok for me if you revert that change. It took me a longer time to figure out how to compile the win natives but I have documented that for me and I'm fine if you restore the original content.

It's totally reasonable to further enhance the documentation and especially to make it more discoverable. The native build instructions are currently indeed difficult to discover. But IMO the solution is not to duplicate the doc more, but instead to add more references to ideally one single source of truth.
With all the clean-up I'm currently doing at the build websites/wiki etc. I really see the downside of having information distributed widely: It's a lot of work to keep it in sync and up to date.
I've now created suggestions for further adjustments:

• Further improve general and native binaries build instructions #3212

Please have a look and let me know what you think or what should be further improved.

And regarding the process, I don't think we should record the discussion about changes in the history of the master branch in git and everybody should just submit his/her proposal and others revert it if they don't like it.
Therefore PLEASE, give others more time to express their opinion and then to discuss a change and to complete this discussion. If you want to make people aware of a PR faster, I suggest to tag them.
But unless a change is urgent (which was IMHO not the case here), I think it's nice to give others at least 24h or better one or two business days to react, especially if others were active in the same area recently. The chance is in general high, that they are also interested in a change then.