Reduce assumptions that scripts start outside Docker

[zultron]

Right now, the scripts mostly assume that they will be started in a shell outside Docker. This conflicts with at least these use cases:

• A Buildbot setup, where the build slave starts scripts from within Docker
• A boot2docker setup, where there is no external shell environment

[zultron]

Probably related to 'Misc fixes #9', 'Refactor options: separate Docker, sbuild, dpkg and apt functions'.

[zultron]

In fact, best would be to include the mk-dbuild scripts inside the Docker container, with the option to mount a dev tree from the host. Then the image could be hosted on the Docker registry with docs about various useful docker run commands. (Also related to above 'Refactor options' issue.)

[zultron]

...And then the mk-debuild scripts could be used for a lot of the configuration in Dockerfile, which really should be tied into the config infra from the scripts.

[zultron]

A bug in Docker versions before 1.1.1 prevents exit status being passed back from docker run -i -t. The top-level scripts therefore can't read exit status.

Not allocating a tty with -t fixes that problem, but then the command output is buffered, which is annoying when a human is watching.

The best fix, outside of waiting for 1.1.1 to come to a distro, is to stop running from outside Docker.