add Tempo, Prometheus and Grafana to docker-compose

[eabasir]

Ticket

Closes #487

Description

I've added the config files needed for Temp, Proemtheus and Grafana (datasources) and updated the docker-compose file to start them. The authentication is intentionally skipped to make it easier for local use.

I've also updated the docker-compose to build the docker file locally and start the container based on the built image. I'm open to further discuss it, but here are my trail of thoughts:

1. I've been troubled using the pushed version of gatewayd image as stated in Gatewayd container exits unsuccessfully on v0.9.6  #568.
2. It would be easier for developers to work with the observability tools and other external services such as Postgres and Redis while developing the service, if the container is created based on the code in the development branch. In other words, having the container built based on the under-development code will facilitate the process of local-development

Development Checklist

• I have added a descriptive title to this PR.
• I have squashed related commits together.
• I have rebased my branch on top of the latest main branch.
• I have performed a self-review of my own code.
• I have commented on my code, particularly in hard-to-understand areas.
• I have added docstring(s) to my code.
• I have made corresponding changes to the documentation (docs).
• I have updated docs using make gen-docs command.
• I have added tests for my changes.
• I have signed all the commits.

Legal Checklist

• I have read the CONTRIBUTING document.
• I have read and understood the Code of Conduct.
• I have read and agreed to the Apache CLA (required).
• I have read and agreed to the LICENSE (required).

[mostafa]

This code looks good to me, except the fact that the installation docs of GatewayD using docker compose assumes that the docker-compose.yml file is self-sufficient, but your changes assume that the user is a developer, hence they have a clone of the repository on their machine. This can be changed in two ways:

1. Have two separate docker-compose files for users and developers.
2. Keep your changes and change the docs to reflect that.

I am more leaning towards the first approach, and I've seen projects use this. Either way the docs should be updated to mention the new changes.

[eabasir]

@mostafa To make the scope of the PR limited I'll proceed with the remote docker image. In another PR we can make different settings for developers