ooil improvements

[mguidon]

Here a list of suggested improvements sorted by my priority:

1. After succesful build of an image it would be nice to be able to verify the labels against the definition. It might still happen that they are screwed up. Specifically nasty are the docker-compose specs. Its possible to have the image labels in there wrong. Not sure how easy it is to test those though.
2. For complex services structure as in https://git.speag.com/oSparc/osparc-s4l there is a lot of duplication in the metadata definition. PyYML should allow have !include directives to include common parts from common files
3. Some of the runtime metadata only exists for dynamic services, e.g. container-http-entrypoint. It seems to be optional and ooil accepts it if its not defined. However, the platform does not allow this. ooil should fail in this case I think.
4. There is some confusion regarding the docker-compose.overwrite.yml. I can use env vars in certain parts (e.g. path to Dockerfile but definitely not in the image. The latter is actually completely ignored and hardcoded to the simcore/services/dynamic/$service_key where service_key needs to be identical in the service key of the docker-compose.overwrite.yml and key in the metadata.yml. I cannot use env vars in the metadata.yml and the runtime.yml. Only $$. The use case for is that for master in the above repo I would like to add the postfix edge to all services via a env var. Alternatively, I could use a templating mechanism
5. There are plenty of OCI related warnings because we do not adhere to this standard. So either we should follow it or remove the warnings
6. I realized that some keys in the runtime.yml (e.g. environment variables and volumes) are discarded but need to enter via the compose-spec. Maybe a linter would help. see also add docs to ooil  #6339. It turns out that we should only define env vars and volume mounts in the compose-spec section. Otherwise the variables that are used in different services with the same name are actually missing! (They seem to show up only in one service)
7. Users that update their metadata.yaml with a new label (e.g. version_display) see a pydantic error when creating the docker-compose-build.yml. Extra fields not permitted. The solution is to update to a more up-to date ooil docker image. I think the user should always use latest and if there are any compatibility issues this should be handled automatically by using the ìntegration-versionthat is actually defined in the same file. This can also happen in theCIwhere we potentially use the sameooil` base image for different services using different features of the tooling.
8. After successful build, ooil-test could verify whether the callbacks defined in the callbacks mapping exist.