Clean up shell scripts in the repo.

[wanglei828]

Current build shell scripts in the paddle repo are spread in different directories, such as docker and travis. Actually, many tasks can be shared by different CI platform and local users also can easily use the scripts to verify their new commit.
I propose to centralize the build tasks into one script. Users can choose different tasks based on their needs. CI scripts can also be simple and clear. Meanwhile, when docker users use container to build paddle, they need to type a long command line (passing many environment valuables ) to start the docker.
For example, we provide two scripts: paddle_build.sh and paddle_docker_build.sh
For users without docker,
paddle_build.sh build ( start build paddle)
paddle_build.sh test (run all the unitest)
paddle_build.sh doc (generate all the doc)
with no options, it will print out the help menu.

For docker users:
paddle_docker_build.sh build
It will first pull the latest dev image from docker hub, start a dev container in the backend and then run "paddle_build.sh build" in the container and exit.
Next time, when you need to build again, you don't need to start container again (if you think you current dev image is OK).
Type "paddle_docker_build.sh test", the test will also be executed in the previous container.

[wangkuiyi]

. Current build shell scripts in the paddle repo are spread in different directories, such as docker and travis. Actually, many tasks can be shared by different CI platform and local users also can easily use the scripts to verify their new commit.

This sounds a good motivation for this change. Could you please elaborate by (1) list all the URLs of build-related scripts in the repo, and (2) list their dependencies so to justify that they could be "shared"?

CI scripts can also be simple and clear.

This reads like your second motivation. I feel like it should be "simpler" and "clearer".

Meanwhile, when docker users use container to build paddle, they need to type a long command line (passing many environment valuables ) to start the docker.
For example, we provide two scripts: paddle_build.sh and paddle_docker_build.sh

The given example is not related to the fact "need to type a long command line"? Is this really an example, or it is actually your proposal?

paddle_docker_build.sh build
It will first pull the latest dev image from docker hub, start a dev container in the backend and then run "paddle_build.sh build" in the container and exit.

By reading this text, I know the different between paddle_docker_build.sh and paddle_build.sh; however, by reading their names, I couldn't have understood their difference.

Is it a good idea to merge them into one, so that the following command

paddle_build.sh

creates the build Docker image from a base image and by adding paddle_build.sh into the image as the entrypoint, and runs the build image. When the script is running inside a Docker container, it doesn't create the image but starts building.

Thanks!