Improve Docker Compose handling

[bartmkraus]

Closes #26

Here's how this solution works:

1. The docker-compose.base.yml contains all shared configuration
2. Backend repo should has its own docker-compose.yml that extends from base and overrides necessary values
3. zeton_full_stack repo has its docker-compose.yml that includes everything including the React client

I think that benefits of this are:

• Single source of truth in docker-compose.base.yml
• Backend repo can work independently
• Easy to maintain as most configuration lives in one place
• Flexibility to override settings when needed
• Preserved all existing functionality including healthchecks

In the near future it would be nice add a docker-compose.override.yml in each repository for environment-specific settings for example: to make local development easier. I think @arkjedrz expressed his concerns about the distinction between production and development environments.

[arkjedrz]

Why is it required to have both docker-compose.base.yml and docker-compose.yml?
It seems docker-compose,yml restates the content.

[bartmkraus]

I've looked a bit into the future with the development and production environments in mind. Maintaining this structure makes it easier to add environment-specific configurations later without having to restructure that configuration. (Core configuration, Development overrides, Production overrides).

[bartmkraus]

Related to this issue: zeton_django Issue #119