Support for nested build steps

This is an nested build implementation roughly based on #7149 by @proppy

### `BUILD /path/to/build/context`
The `BUILD` instruction starts building a new image as if `docker build` would
have been run in the specified directory of the current image. Rest of the
instructions in the Dockerfile are now considered to be part of this new build
process. If there are no instructions and the context directory contains a
file called Dockerfile then this file is used instead. Files located in build
context directory are available as source paths to the ADD and COPY commands.
No previously set instruction has any effect to the new build.

Consider a Dockerfile:

```
FROM crosbymichael/golang
ADD . /go/src/github.com/tonistiigi/dnsdock
ENV CGO_ENABLED 0
RUN cd /go/src/github.com/tonistiigi/dnsdock && \
    go get -d ./... && \
    go install -a ./...

BUILD /go/bin

FROM scratch
ADD dnsdock /
ENTRYPOINT ["/dnsdock"]
```

Running `docker build -t tonistiigi/dnsdock .` will result in the creation of following images:

```
> docker images
tonistiigi/dnsdock          latest  3f7a44c4701a  6 seconds ago    7.844 MB
tonistiigi/dnsdock-builder  latest  dac44acfcdd9  10 seconds ago   474.7 MB
```

The final image is minimal, containing only a static binary compiled by previous image. Builder layers are kept to keep build cache working.

Parent build step can be also used for dynamic Dockerfile creation. In this case `BUILD` instruction needs to be the final instruction in the Dockerfile.

```
FROM ubuntu
ADD . /src
RUN /src/build-new-dockerfile.sh > /src/Dockerfile
BUILD /src
```

Number of build steps isn't limited. Last image gets the tag.

```
cat <<EOT > Dockerfile
FROM busybox
RUN /bin/mkdir -p /out && /bin/touch /out/a
BUILD /out

FROM busybox
ADD . /out
RUN /bin/mkdir -p /out && /bin/touch /out/b
BUILD /out

FROM busybox
ADD . /out
RUN /bin/mkdir -p /out && /bin/touch /out/c

EOT

docker build -t abc .
docker run abc /bin/ls /out

# prints:  a   b    c
```

I realize that the proposals with different solutions for fixing this problem have not yet been agreed on by the maintainers. Just hoping that having one implementation ready for testing/review brings the final solution for minimal containers closer for everybody.
Yes I did.

The problem is that if we just remember the current job and clone it then we would break usage of  this package just by its public api. It would have to be changed so that you can only build from a Job object.

If you mean making a new Job from the properties of the current Builder then this would mean maintaining a double logic of how a Job is converted to a Builder and how a Builder is converted to a Job. I think this part changes quite often with new features and if its not perfectly in sync then bad stuff can easily happen.

Up for discussion of course. Maybe I'm missing some important value that having a separate Job adds. Shutdown and logging should work the same AFAIK.