Regenerate the EMF models of org.eclipse.e4.ui.model.workbench

[merks]

• Fix spelling mistakes in the Ecore model so they don't reappear in the generated code.
• Change the GenModel compliance level to 21.
• Configure the project-specific cleanup action to include instanceof cleanup which is not part of the Eclipse [built-in] profile so that the cleanup of the generated code includes that action.

[merks]

While looking at eclipse-pde/eclipse.pde#1974 I noticed that other GenModels, the ones in this PR, could no longer regenerate the code and they generated results that undid the cleanups.

With this PRs changes, the generator will do the same cleanups, including the instanceof cleanup, and is able to generate clean code. I had to change the project-specific preferences in a "not so nice way". Most of the generated changes are whitespace/formatting changes except for the two files that @iloveeclipse modified by hand.

@iloveeclipse

It is possible to preserver your changes to PartImpl and UIElementImpl. One might change the @generated annotation to @generated NOT. But then in the future if the model is changed the toString method will not pick up the changes. One might in addition to that introduce a toStringGen method, and not call it, but leave it in the code so that if the model changes and that toStringGen method then also changes, maybe someone will think hard enough to modify the hand modified methods with the corresponding changes. Please let me know your thoughts about this; I don't want to just overwrite your changes without your involvement.

[iloveeclipse]

It is possible to preserver your changes to PartImpl and UIElementImpl. One might change the @generated annotation to @generated NOT. But then in the future if the model is changed the toString method will not pick up the changes. One might in addition to that introduce a toStringGen method, and not call it, but leave it in the code so that if the model changes and that toStringGen method then also changes, maybe someone will think hard enough to modify the hand modified methods with the corresponding changes. Please let me know your thoughts about this; I don't want to just overwrite your changes without your involvement.

OK, the commit was 168689f and the aim was to reduce "noise" from toString().

I would like to "freeze" the code "as is", assuming if someone would need to see new attributes in debug output it is an easy task to add them manually.

So what is the simplest solution to keep the code "as is"?

[merks]

So what is the simplest solution to keep the code "as is"?

I described the changes I made to preserve your toString changes.

OK?

[github-actions]

Test Results

 2 904 files  ±0   2 904 suites  ±0   2h 16m 55s ⏱️ + 7m 6s
 8 019 tests ±0   7 774 ✅ ±0  245 💤 ±0  0 ❌ ±0 
23 597 runs  ±0  22 815 ✅ ±0  782 💤 ±0  0 ❌ ±0 

Results for commit 9c666db. ± Comparison against base commit fbad80e.