client: split interfaces into smaller ones

The client defines various interfaces, all of which are combined into an
overall "Client" interface. https://github.com/moby/moby/blob/client/v0.1.0-beta.0/client/client_interfaces.go#L24-L223

While the interfaces already have been (partially) split up to be grouped
by object-type (e.g. "containers", "images"), some of these interfaces
are still overly broad. In addition, some unrelated methods are combined
in a single interface; for example, ImageBuild and ImageSearch are part
of the ImageAPIClient interface, but ImageSearch is just a proxy to
reach the (docker hub) registry search service.

We must decouple such interfaces, more importantly, with the Classic Builder
(and its API), being deprecated, and ImageSearch currently only covering
Docker Hub registry "v1" image search, they are non-essential features of
the CLI.

Similarly, ContainerExec (and related) are part of the ContainerAPIClient.
which may be "correct", but could be split up into its own interface.

Having shallower interfaces allows for more flexibility; consumers of the
module can "cherry-pick" parts of the client's interface and compose them
into their required functionality.

Splitting the interfaces also allows more flexibility to deprecate parts
of the client if needed, or to implement separate clients in sub-packages
to provide a subset of the features.

Given the RESTful(ish) implementation of the current API, we likely want
to have at least a per-object-type CRUD interface for the minimal operations.

Other parts to look at are "Prune" operations;

ContainersPrune(ctx context.Context, pruneFilters filters.Args) (container.PruneReport, error)
BuildCachePrune(ctx context.Context, opts BuildCachePruneOptions) (*build.CachePruneReport, error)
ImageTag(ctx context.Context, image, ref string) error
NetworksPrune(ctx context.Context, pruneFilter filters.Args) (network.PruneReport, error)
VolumesPrune(ctx context.Context, pruneFilter filters.Args) (volume.PruneReport, error)

With the migration to the containerd image store, and the intent to start
moving towards garbage-collection (alleviating users from manually micro-
managing storage), these interfaces may become less critical, and could
even become obsolete. We should express this in the interface definitions.

When evaluating, we also must look at some of the "global" methods specific
to the client itself;

	ClientVersion() string
	DaemonHost() string
	HTTPClient() *http.Client
	ServerVersion(ctx context.Context) (types.Version, error)
	NegotiateAPIVersion(ctx context.Context)
	NegotiateAPIVersionPing(types.Ping)
	HijackDialer
	Dialer() func(context.Context) (net.Conn, error)
	Close() error