Introduce Dockerfile versioning

[Sinclert]

This PR addresses several issues regarding Docker images and Dockerfile definitions:

1. Lack of incremental versions (v0.1.0, v0.2.0...).
2. Presence of legacy code (C++ patches over the MadGraph5 library) not longer needed.
3. Duplication of Dockerfile commands over different use-cases (all, ml and physics).
4. Indetermination of how to install custom binary dependencies (MG5_aMC_v2_6_X).

What is introduced:

In order to define Docker images versioning, new Makefile and VERSION files have been defined for each of the use cases. The Makefile offer 2 entry-points so far: build and push (although it can be expanded in the future).

To operate with them, simply:

$ cd docker-images/<use_case_folder>
$ export DOCKERUSER=<your_username>
$ export DOCKERPASS=<your_password>
$ make build
$ make push

Additionally, Dockerfiles have been reorganized and now follow the similar building order:

1. Base image.
2. Copy files.
3. Install Linux packages.
4. Install custom binaries.
5. Install Python requirements.

This definition, facilitates the identification of similarities across Dockerfile definitions. Due to this change, the Dockerfile for the "all" use case has been now defined using the "physics" Docker image as base (instead of repeating most of their commands).

Finally, the installation of the MadGraph5 dependency has been move inside the Dockerfile, as shown by this reference example.

[Sinclert]

As a future proposal, I would suggest moving all the MadGraph 5 installation to a new Dockerfile, being hold in the original MadMiner repository.

It will provide a better responsability separation between:

• The library (MadMiner with their dependencies).
• These examples (the ones operating on Madminer with Python files).