chore: Some tokenizer as language module

[miurahr]

Tokenizer is used for the project in which the source or target language is the same as the provided one.
It is feasible to move tokenizers to the corresponding language module.

Pull request type

• Build/release
• refactoring

Which ticket is resolved?

What does this PR change?

• Move Japanese, Chinese and Polish tokenizers to the corresponding language module.
• There are derived from 3rd party analyzer library, that are not mandatory for other languages.

Other information

Depends on #1183

[github-actions]

❌ Quality checks failed.

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

[github-actions]

❌ Acceptance Tests failed.

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

[github-actions]

❌ Acceptance Tests failed.

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

[github-actions]

❌ Quality checks failed.

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

[miurahr]

There is no obvious benefit to move tokenizer classes to language-module and change package paths. Most tokenizers come from Lucene-analyzer-common library that is a mandatory library of OmegaT core. There are three languages that can be justificated for the change; Japanese, Chinese and Polish that are provided their special analyzer.

[github-actions]

❌ Quality checks failed.

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

[github-actions]

❌ Acceptance Tests failed.

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

[miurahr]

This is not feasible to split tokenizer to module. I want to give up here.