Restructuring Pynequa

[anisbhsl]

This is an open issue to have discussions on restructuring pynequa hoping it will serve as documentation for future changes.

Currently, pynequa is organized as follows:

pynequa
|
|- core.py # contains main REST API method implementations for Sinequa
|- models.py # data models
|-api
   |-api.py # contains HTTP request implementations

This was the initial implementation of pynequa. With incoming changes, it is now time to think of re-structuring classes and separate search, index, collection, engine, extras implementations.

### Tasks
- [ ] https://github.com/NASA-IMPACT/pynequa/issues/15
- [ ] https://github.com/NASA-IMPACT/pynequa/issues/16
- [ ] https://github.com/NASA-IMPACT/pynequa/issues/17
- [ ] https://github.com/NASA-IMPACT/pynequa/issues/19

[anisbhsl]

Ideas to refactor the core.py module

As of now, the core module includes implementation of all search methods. As further development on this package continues, there is a need to add other group of API method implementations (e.g. search, index, general, operation). My proposal is to keep the core Sinequa class as it is and spread other methods into multiple subclasses.

Right now, Sinequa class inherits API class which implements the GET and POST API requests. I am thinking of allowing the end client to access all other methods through single class Sinequa while breaking them into different modules internally. To outer user, it will appear as single class. The sample usage might look like this:

sinequa.search.search_query(....)
sinequa.index.custom_collection(...)
sinequa.operation.collection_start(...)

Feel free to provide your thoughts on this.

cc: @NISH1001