Update docker images and provide examples

[erubboli]

This PR adds more images for api-blockchain-scanner-daemon, api-web-server, dns_server, wallet-rpc-daemon and removes the image for node-gui. In addition runs the commands as normal user (mintlayer) instead of the default root user.

TODO:

• Ensure all ports are correctly exposed (default to mainnet).
• Add/fix documentation (will be done separately)
• Add an example to run a whole block explorer in a docker-compose file. (it's better to do this in the block explorer's own repository)
• Fix binding host on api-web-server and, if necessary, the other tools (e.g., --rpc-address node-daemon:3030 should work).
• In Docker, it is very common to pass configuration details using environment variables so that this can work:

api-web-server:
  image: mintlayer/api-web-server:0.3.0
  environment: 
    - RPC_ADDRESS=node-daemon:3030 
    - POSTGRES_HOST=postgres 
    - POSTGRES_PASSWORD=use-strong-password 
    - POSTGRES_DATABASE=mintlayer_chain

[ImplOfAnImpl]

So, I've taken over this PR and pushed some commits. The PR is curently based on the "fix/locked-utxo-conflict" branch, because that branch contains some fixes required for api scanner daemon to work properly.

1. Block explorer example hasn't been and will not be added here. Though technically it's not hard, Sam is against it. The main reason is that the block explorer is not core devs' responsibility; we don't want to have to support it. The better way should be to put the corresponding example into the block explorer's own repository.
2. All services are put into the same docker compose file; users are supposed to copy the directory and comment out the services they don't need.
   The exception is dns-server, which has its own separate compose project.
   (This is a Sam's suggestion as well; initially I put unrelated services into diferent yml files and it worked, but it was kind of inconvenient to use).
3. Instead of using a named volume, I just map the home directories of containers to a directory on the host machine; the latter is always a subdirectory of the current directory (i.e. the one that contains the docker compose files). This way, the user will have a predictable location for their data (wallet files in particular). Again, this approach assumes that the user will copy the docker compose project to a separate location.
4. The host system's directory where containers' home directory is mounted must be writable by the containers. It'll be the responsibility of the user to ensure it is. To make it possible, dockerfiles create 'user' and 'group' with the explicit uid/gid of 1000. Chances are that host system's 'user' will have the ids of 1000 as well, so nothing will have to be done in this case. But even if not, at least the user will know which 'user' should be granted access to the mount point.
5. I also removed the EXPOSE lines from docker files, because they don't do anything except for serving as documentation and IMO they are more misleading than helpful.

Regarding the question whether we should have the ability to run wallet-cli via docker compose.

1. I don't see why not. It's useful to have.
2. Running interactive shells via docker compose is possible and people do it (in the context of crypto wallets too).
   There are basically 2 ways to do it - via docker compose run, which starts a new container based on a service definition, and docker compose exec, which runs a command in an already running container.
   The "run" approach was the first I tried. I had to have an additional yml file for the wallet-cli service in this case, which then would have to be run like this:
   docker compose -f docker-compose.wallet-cli.yml -f docker-compose.yml run --rm wallet-cli
   But in the end I decided to put the wallet-cli binary into the same image as node-daemon, so now it's possible to run it via "exec":
   docker compose exec node-daemon wallet-cli
   And the separate docker-compose.wallet-cli.yml is not needed anymore.
   Also, because the separate docker image for wallet-cli has become redundant, I removed it.

[TheQuantumPhysicist]

Besides the comments, this looks fine. I want Enrico to review it though to see if this is what he expects.

[ImplOfAnImpl]

I've revamped dockerfiles once more. Now they don't use the USER directive; instead, there is the entrypoint.sh script, which is run as root initially and which then creates the user, chown's the mounted mintlayer-data directory and runs the passed executable as the user.
Basically, the main reason for this script to exist is the abovementioned chown call (because there is no other place to do this except as a part of CMD or ENTRYPOINT directive). But it also adds the possibility to specify the user id in the environment instead of hard-coding it in the docker file.

[TheQuantumPhysicist]

Besides the p2p port issue, this is looking OK at this point.