Do not segregate the app docs and settings/code based on ENVIRONMENTS

[rragundez]

At this moment there is quite of complexity in the documentation and in the code because of this concept of trying to differentiate in "non advice only" between different environment.

I think the code should just be with its functionalities and thi stuff about different environments should end up only in recommendation of settings/environment variables.
For example, I do not think there should be any limitation or separate dockerfiles or .envs or anything duplicated in the code to try to handle or differentiate between cors origins regardless of which enviropnment the user will deploy on. It should just work. 1 single version of the code. The only difference is in the documentation, not by showing different version of the .env file but by advicinb that CORS ORIGINS should not be set to * when running in production because bla bla.

This removal of the concept of an environment will simplify the docs mainly but the code as well. Allowing the user to navigate so much easier via the information and make its own decision.
Perhaps the only difference should be if running locally or deployed somewhere, there i might argue than indeed there might be a difference, mainly the use of the .env file, the use of the dockerfile without docker compose and the logging to a file, if I think about it I think that is the actual difference the user should be concern about in code/architecture.

[rragundez]

@igorbenav let me know what you think