BuilderParticipant.doBuild behaviour is order dependent

The behaviour of BuilderParticipant.doBuild behaviour is order dependent.
it does the cleanDerivedResources on per file level.
thus the guard in cleanDerivedResources that does a if (derivedResourceMarkers.findDerivedResourceMarkers(iFile).length == 0) {
will not match if the "add" delta is proccessed after the "remove"
and "add" and "remove" lead to the same generated file
(e.g. when the dsl supports file shadowing similar to java or you move a file from one to another source folder)

the problem with this behaviour is that the resource event for the derived resources
differs (delete+add, change, no event) which might affect downstream toolchains

so i wonder if first all generators should be called and then the cleanup should take place
or if we should sort the deltas and move "removes" to the end of the deltas list

Start by tracing BuilderParticipant.doBuild and its per-file calls to cleanDerivedResources, then inspect how derivedResourceMarkers.findDerivedResourceMarkers is evaluated across add and remove deltas. Reproduce a move or shadowing case where both deltas produce the same generated file, and verify that the resulting derived-resource event is consistent for downstream toolchains.