Provide a `New` method and a new `Run` method on the `grpcClient` to allow
manual creation of a client in addition to the current ability to initialise
from the environment. Accordingly the existing `Run` method becomes
`RunFromEnvironment`.

Signed-off-by: Ian Campbell <ijc@docker.com>

Returning an interface rather than a private-struct from a public interface is
good practice.

Signed-off-by: Ian Campbell <ijc@docker.com>

…e cases.

Refactor the setting/getting of the result for a `llbBridgeForwarder` in order
to check that `Return` is only called once and only with the correct options.

Signed-off-by: Ian Campbell <ijc@docker.com>

Avoids panicing when accessing `creq.Definition.Metadata`.

Signed-off-by: Ian Campbell <ijc@docker.com>

Reorder the code slightly so that an error returned by the call to the
`BuildFunc` is picked up by the `defer`d error handling.

Signed-off-by: Ian Campbell <ijc@docker.com>

This allows builder code to be written which can be built as either a gateway
container or in a purely client side configuration, giving implementors more
flexibility.

Now when `Solve` sees a request with neither a definition nor a frontend
specified it will make the job available via new LLBBridge endpoints on the
control socket which the client can then use. These end points require the job
id to be present in the gRPC metadata and a client side object is added to
facilitate this.

The `llbBridgeForwarder` type is now exposed as a public `interface
LLBBridgeForwarder` which satisfies the underlying gRPC server interface
(`pb.LLBBridgeServer`) as well as a new `Done()` & `Result()` pair which can be
used to wait for the client to call `Return()` (using a model similar to
`context.Context`).

Signed-off-by: Ian Campbell <ijc@docker.com>

Adds an option/envvar to `examples/build-using-dockerfile` which uses a client
side instance of the dockerfile frontend.

Signed-off-by: Ian Campbell <ijc@docker.com>