Bug 1384499

Description of problem:
doing `scl enable rh-ruby23 some command` does not replace scl wrapper process with the command but executes command as a sub-process.

This is creating an unnecessary process nesting and is problematic in some scenarios.

One example is running inside a container. the `scl` becomes PID1 but it cannot adopt and clean dead children processes.
Another example is in scirpting, one may expect to do something like:
scl ... &
pid = $!
kill -9 $pid

But this would not kill actual process, only the SCL wrapper process.

I believe `scl` should run processes in way similar as much as possible to running same processes without scl. IMO this is the point of SCL.

Version-Release number of selected component (if applicable):
RHEL7

How reproducible:
always

Steps to Reproduce:
1. scl enable rh-ruby23 -- sleep 1000 &
2. ps -ef

Actual results:

> default       1      0  0 12:06 ?        00:00:00 /usr/bin/scl enable rh-ror42 -- /usr/local/bin/run-jnlp-client ...
> default       6      1  0 12:06 ?        00:00:00 /bin/bash /var/tmp/sclPDpKGu
> default      21      6  5 12:06 ?        00:00:06 java -cp /home/jenkins/remoting.jar hudson.remoting.jnlp.Main ...

Expected results:

> default      1      0  5 12:06 ?        00:00:06 java -cp /home/jenkins/remoting.jar hudson.remoting.jnlp.Main ...

Additional info:
Basically I would expect that scl and helper script to be replaced by the actual process user cares about. Not sure about exact change needed in the `scl` binary but the content of helper script /var/tmp/sclPDpKGu is this:

> eval "SCLS=( ${X_SCLS[*]} )"
> /usr/bin/scl_enabled rh-ror42
> if [ $? != 0 ]; then
>   SCLS+=(rh-ror42)
>   export X_SCLS=$(printf '%q ' "${SCLS[@]}")
> . /opt/rh/rh-ror42//enable
> fi
> "/usr/local/bin/run-jnlp-client" ... 

I would expect last line to be:

> exec "/usr/local/bin/run-jnlp-client" ...