Update and clarify Docker

[nuest]

Re-check that the export and import can use the ERC identifier as it is in the spec.

• [ ] remove URI as a variant for ERC id and make UUID a must
• [ ] extend core spec that UUID must be created properly during ERC creation
• [ ] to Docker extension, add code statement how to tag the image to section "Docker container", rephrase section to "MUST use these commands to create the image file"
• [ ] image.tar name is a MUST not a SHOULD (also in "Docker container")
• [ ] remove "Docker container" section, we actually want to save the image not export the container
• [ ] "Default control statements" potentially better named "Docker container control"
• [ ] add example for valid but not the default statements (with my_image.tar in load and myimages:latest as tag in the run statement)
• [ ] add example command/implementation hint for extracting the workspace from a container that has completed, e.g. docker cp erc:.../erc /host/path, which must be done so that an ERC can be validated
• [ ] add sentence to Validation in core spec: "Prior to validation the output of an ERC execution must be extracted from the nested runtime environment."
• [ ] add example to "Runtime manifest" in core spec, "e.g. a Dockerfile".
• [ ] add section to Developer Guide: Add section "Implementation hints" and add "How to implement validation" and connect the docker cp stuff with Validation

[nuest]

• [ ] update the control statements to specify explicitly where a "load" and "execution" command??
  • issue: we describe that the ERC base directory MUST be mounted, but in the execution command there is not mount!

execution:
  prepare: `docker load --input image.tar`
  start: `docker run -it -e TZ=CET erc:b9b0099e-9f8d-4a33-8acf-cb0c062efaec`

Then, we cannot list all possible options of docker run or prohibit all of them... maybe the Docker run command should not be put here, but instead a well-defined list of it's inputs. Then, an implementation can easily create the run command including all the other options it may want to use (like performance options etc.).

The latter approach would also be better as not explicitly putting in docker load and docker run means users cannot expect us to list docker rm and docker rmi as well!