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

[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 the fact that my main_package had its own independent openapi specification file. While on the other hand 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 packageName as its root package to refer to main_package api_client.
sub_package_1 config file:

{
  "packageName": "main_package",
   "invokerPackage" : "sub_package_1",
   "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 append_submodule_api_details.mustache and append_submodule_model_details.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 __init__package_submodule.mustache which acts as a sub package init.py file without referring to api_client of main_package.
   commit 1
   commit 2

2. Added reference of main_package/api and main_package/models in main_package/init.py so 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
   commit 3

4. Usage of Invoker package to create path to generate sub package's api, models and package init.
   commit

[rienafairefr]

have you tried the -DgenerateSourceCodeOnly=true parameter ? This will generate a subpackage, and with the dotted package name fix it's a start.
What happens if sub_package_1 or sub_package_2 use different parameters ? like auth parameters, hosts, etc, all the parameters that are used in the templates for configuration.py/api_client.py ?

[VamshikShetty]

@rienafairefr as you can see in my PR description generateSourceCodeOnly of sub_package config is already set to true, this combined with new parameter named invokerPackage will cover a case where sub_packages want to have common configuration.py/api_client.py.
If a case where requirement of different parameter arises then it is already taken care of because the current codegen will always produce configuration.py/api_client.py for each sub packages.