make shell for exploration when building rpm-code

[e-carlin]

Frequently I do this while working on getting an rpm-code build:

1. add a sleep 99999999999999999999 somewhere in the build right before a step that is failing
2. docker exec into the build container
3. run whatever bits of code.sh I need to get enough of an environment setup to run commands to troubleshoot the problem
4. use some combination of docker tramp and copying files to edit files

What I'd like to do is:

1. bash run-build.sh manual
2. have the dir where codes_download puts things mounted in a volume that lives outside of the container
3. get dropped into a shell where I have the full installer env setup
4. be able to edit files on my host and have the changes appear in the container

[robnagler]

I think we should control with an environ var, since we already have build_debug. Maybe build_interactive, or we could change the meaning of build_debug (which perhaps this mode would eliminate).