[feat] Set a simple, independent version file for the current dynamic development and potential environment incompatibilities

+ @pkarw I'm wondering if we shouldn't add some temporary `VERSION` file in which we will change the version when some important things change... and then during the application run, inform the user that he has an incompatible version and should check his `.env` files, because the user - even now - won't know that we added some configurations, etc., and his `.env` will be old. Of course, we should keep backward compatibility, but I think that we can't predict everything, and before we publish the official package, we should go with something like:
- Push to `VERSION` something like (...) 3 (I would go with int, it's not about semver here and we won't update it every time).
- Push to `INCOMPATIBLE_CHANGES` a simplified changelog which has a structure like:
```
--2--
(incompatible changes between 1 and 2)
--1--
(incompatible changes between non version and 1 version)
```
- After comparing, we will show messages to the user.
- Push to `.env.example` `TEXT_EXTRACT_API_VERSION=3`.
- Push to `.env.localhost.example` `TEXT_EXTRACT_API_VERSION=3`.
- In the run scripts, check:
- If `.env` or `.env.localhost` exists, check both of them:
- Missing `TEXT_EXTRACT_API_VERSION` -> old.
- Lower than `.repository_version` -> old.
- If not, then do nothing.

And in case of finding an old version:
- Ask the user to update his `.env` file based on `.env.dist` (we should change the name from `example` to `dist` because it's like variables that the user should acknowledge).
- Ask the user to clean up his `.venv` (usually done with `make`).
- Tell the user about possible changes.