A second round of refactoring changes

[kirlat]

This is an implementation of all the valuable suggestions that I've received during the first PR, and some other improvements as well. It's still not fully production ready and many tests are missing; I'm working on that.

The purpose of this PR is to offer for discussion and finalize a new architecture. Once it's set, I can add reliability improvements whenever necessary to be sure it handles all edge cases well.

The most significant changes are:

• Job steps are split into their own classes, as suggested by @irina060981. I've decided to represent them as value objects with the retrieve() non-static method. That decision was partially based on the StackOverflow discussion. Adding a new source of data would require to create a new class for it and add that class the execution path. It should be pretty easy.
• First I've decided to move execution path out of the WordQuery but then I've realized that nothing will be left within the WordQuery class after that. So I decided to leave the execution path where it was, within the WordQuery. The WordQuery now, in fact, is the execution path because there is not much else there. Do you think that this is OK?
• WordQueryResult has been renamed to the WordQueryResponse to better reflect its role.
• I found a way to simplify "live" tracking of query results by using just a simple callback. This allowed to get rid of the proxied version of the WordQueryResult and simplified code a lot. It also provided more flexibility as we can chose the moment to call the callback, and we can do that at moment where a WordQueryResponse would guaranteed to be in a consistent state.
• In order to standardize communication between objects further I've decided to add a LexicalDataResponse class that represent a result of a singe job. This makes communication more predictable and consistent. Results of several jobs are stored in a map with the key being the job name. This map is passed to each job data object so they could use data from previous job steps if necessary.
• I've added a more standardized error handling and created a mapper between the client adapters and the GraphQL error formats. An enum class was created for error codes. However, the way errors are handled in GraphQL, error codes, messages, etc. is still up to discussion.
• WordQueryAdapter has been renamed to the WordQueryController to better reflect its purpose, upon a @balmas suggestion from a previous PR.

Please let me know what do you think. Thanks!

[kirlat]

perhaps we should subdivide them into logical groups? useMorphService, useTreebankData useWordAsLexeme are all only relevant for getLexemes so they could be properties on the getLexemes option treebankProvider, treebankSentenceId, treebankWord ids could be subproperties on useTreebankData lexicons, shortLexicons could be subproperties on getShortDefs

Great suggestion! I hate long lists of parameters. I will update the code accordingly.

[kirlat]

@kirlat , I didn't find any tests for your changes for new workflow for LexicalQuery. And also I could see that some tests are skipped. Do you have an opportunity to create tests for GraphQL workflow? To create some scenarios with different execution paths and see the way it goes through conditions with observable quiery? With different languges?

I'm working on adding more tests right now, I'm planing to merge once the tests will be ready.