Support to generate python client binding sub packages independently using different OpenApi specification file

Created by: VamshikShetty

PR checklist

• Read the contribution guidelines.
• Ran the shell script under ./bin/ to update Petstore sample so that CIs can verify the change. (For instance, only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh, ./bin/security/{LANG}-petstore.sh and ./bin/openapi3/security/{LANG}-petstore.sh if updating the {LANG} (e.g. php, ruby, python, etc) code generator or {LANG} client's mustache templates). Windows batch files can be found in .\bin\windows\.
• Filed the PR against the correct branch: master, 3.4.x, 4.0.x. Default: master.
• Copied the technical committee to review the pull request if your PR is targeting a particular programming language.

@taxpon @frol @mbohlool @cbornet @kenjones-cisco @tomplus @Jyhess

Description of the PR

I was faced with the issue of modularising my api methods into different section, this need arised due to fact that my main_package was independent openapi spec which had few api methods and I had N number of sub packages which had their own independent openapi spec files but lets say that a user only wants selective k packages to be installed independently hence using this merge he can generate selective k binding by running Codegen k times with new specification files of each subpackage, while making sure all sub_packages refer to common api client, configuration and rest python files i.e structure should be similar to :

This particular PR talks foundational bug which was later resolved in it.

So lets say if user wants to install sub_package_1, sub_package_7 and sub_package_13 (assuming main_package is default) then First he create main_package normally like any openAPI auto generated client bindings by passing openapi specs and config file. config file:

{
    "packageName":"main_package",
    "projectName":"python-main-package",
}

Then by generating openapi bindings of sub_package_1, sub_package_7 and sub_package_13 but considering client's main_package as its invoker package i.e : sub_package_1 config file:

{
  "packageName": "main_package.sub_package_1",
   "invokerPackage" : "main_package",
   "generateSourceCodeOnly":true
}

This led me to use a new parameter named invokerPackage in config file.

Changes that I have done:

1. I have added three new mustache files, first two __init__api_submodule.mustache and __init__model_submodule.mustache files are used to create content that will be append into main_packge/api/init.py and main_packge/model/init.py respectively. And third one acts as a sub package init.py file without referring to api_client of main_package. commit

2. Added reference of main_package/api and main_package/models in main_package/init.py so it main package init can point to sub packages classes which are referred in main_package/api/init.py. commit

3. Merge function added to add details of new api classes to main_package/api/init.py which is generated at the time of sub_package generation also sub_package models details to main_package/models/init.py commit_1 commit_2

4. A invokerPackage parameter passed when sub package is being generated to give reference from sub package to main package api and model files. commit Correction added to make sure single client generated binding can act as part of a module as need here hence just a small correction i.e commit