Refactor API for generator command line interface implementation

[rszamszur]

• I have searched the issues of this repo and believe that this is not a duplicate.

Feature Request

Currently, implementing custom generators might be confusing since one needs to access "self" via click.Context class object instance for a given generator command:

import click
from fastapi_mvc import Generator

...

@click.command(
    cls=Generator,
    # Or use repository address
    template=os.path.dirname(__file__),
    category="Custom",
    ...
    alias="foo",
)
@click.argument(
    "NAME",
    required=True,
    nargs=1,
)
@click.pass_context
def foobar(ctx, name):
    ctx.command.ensure_project_data()

    data = {
        "project_name": ctx.command.project_data["project_name"],
        "name": name.lower().replace("-", "_"),
    }

    ctx.command.run_copy(data=data)

Not only this might be misleading but it does not guarantee that ctx.command will be an instance of a Generator class. Moreover, this won't pass type checking (that will be added soon). IMHO, an approach where generators utilities are coupled with Generator command line interface class not only breaks the single responsibility principle but also adds an unnecessary layer of complexity. In the end, most of the utility methods were static anyways. Lastly, I also think it's better to use copier directly rather than via wrapper.

This refactor will be a bit chaotic due to limited time resources, and some degree of unknown. General plan:

1. Refactor Generator.poetry_path method to shell utils
2. Refactor generator utilities into a separate submodule
3. Refactor constants into separate submodule
4. Refactor Generator.insert_router_import method into the controller generator
5. Rename Generator class to GeneratorCommand
6. Drop copier wrappers
7. Update docs
8. Update tests
9. Anything else in order to facilitate this change

Lastly, a copier-generator template will have to be updated to work with the new API for creating generator's CLIs.