refactor: migrate markers as first class plugins

[miurahr]

• Deprecate Core.registerMarker and Core.getMarkers
• Remove MarkerController.init and WhitespaceMarkerFactory.init

Pull request type

• Other (describe below)
  refactor

Which ticket is resolved?

What does this PR change?

• Make NBSPMarker as true plugin
• NBSP marker menu are created in the plugin
• Removal of hard coded menu creation
• When registering maker plugins with its class, and loading the plugin, static fields are initialized when loadPlugins static function is called. it breaks colors of markers.

Other information

[github-actions]

❌ Run Gradle test failed:

[github-actions]

❌ Run Gradle test failed:

[github-actions]

❌ Run Gradle test failed:

[github-actions]

❌ Run Gradle test failed:

[github-actions]

❌ Run Gradle test failed:

[github-actions]

❌ Run Gradle test failed:

[miurahr]

Now these 6 maker become true plugins.

    org.omegat.core.spellchecker.SpellCheckerMarker \
    org.omegat.gui.glossary.TransTipsMarker \
    org.omegat.gui.editor.mark.BidiMarkers \
    org.omegat.gui.editor.mark.ComesFromAutoTMMarker \
    org.omegat.gui.editor.mark.FontFallbackMarker \
    org.omegat.gui.editor.mark.ReplaceMarker \

Menu Items are generated dynamically using marker plugins IMarker interface.

[github-actions]

❌ Run Gradle test failed:

[miurahr]

I propose addition of method void reloadDocument(); in IEditor core interface, that reload project contents and redraw markers when project is loaded.

[github-actions]

❌ Run Gradle test failed:

[github-actions]

❌ Run Gradle test failed:

[github-actions]

❌ Run Gradle test failed:

[github-actions]

❌ Run Gradle test failed:

[brandelune]

@t-cordonnier review appreciated ! :-)

[t-cordonnier]

@t-cordonnier review appreciated ! :-)

@brandelune I already sent some comments in this ticket.

I notice that now the menus are more dynamic as I suggested, good point. So, there was an evolution since my last comments, which I was not alerted about, so for me it was still pending.

The rest of the code seems unchanged so I maintain what I said: I would prefer one or more sub-interfaces to distinguish between non-skippable markers (the ones which are always active), menu markers (the ones which have a menu with an icon to activate/inactivate) and eventually, those which are skippable but whose configuration is done in another location than in a menu.
I remember in the past Aaron wanted to avoid casts, but maybe @miurahr can have a different position. I let to him the final decision but for the moment I saw not even a reaction to my comments.

[github-actions]

❌ Unit Tests, Quality checks, and Acceptance Tests failed.

Please look a Gradle Scan page for details:
https://gradle.com/s/5fvmgyfz4sao4

[github-actions]

❌ Unit Tests, Quality checks, and Acceptance Tests failed.

Please look a Gradle Scan page for details:
https://gradle.com/s/s44bp44nv2ppw

[github-actions]

❌ Unit Tests, Quality checks, and Acceptance Tests failed.

Please look a Gradle Scan page for details:
https://gradle.com/s/tysmlnn7dboyo

[miurahr]

The change does not provide a benefit over the task.