make 'set' more transparent

[maxfl]

The issue is connected with #206 and #158.

Set variable get the stdin and returns it's return code, but it's often needed to use set with command substitution and pass std in to the subcommand and get the return code om subcommand.

1. The option can be added to 'set' asking not to overwrite $status variable if set succedes.
   In this case both 'set' and subcommand can set non-zero exitcode if anyone fails. It's a bit ambiguous, but not harmful, since
   the user is interested in both: setting variable and subcommand returning 0.
   Technically it can be done by reserving one particular exitcode (for example -1) for internal use. As far as I know system can use
   the codes in a range 0-255. All other codes are truncated. So we are not going to interfere with any program.

2. While 'read' can be used to set put the stdin to variable, the fact that set catches the output looks somewhat ugly.
   But I guess technically it can be quite a difficult to change it. Is there a simple way to forbid set getting stdin and putting it to the first command substitution instead?

[ridiculousfish]

I thought about casting this as an option "set --if" so if $status is nonzero, set fails with the same status. But I think we would want set to actually modify the variable with the output, even if the command substitution reports failure.

[ridiculousfish]

Another possibility is to make this behavior the default. If for some reason you are interested only whether set succeeded, you could workaround it in the command substitution instead.

[ridiculousfish]

This is complicated by the fact that the exit status from subcommands is just discarded. That is ,set does not have access to the exit status of any subcommands expanded in its arguments.

[ridiculousfish]

I went ahead with this: ad8d68d

Now set does not modify the exit status, except if it fails or when passed -n (names), -e (erase), or -q (query).