Provide a way to source shell-specific startup files for noninteractive commands

[Ivan Pozdeev]

(searched through the list archives and elsewhere and didn't find any prior relevant discussions.)

I'm one of Pyenv project maintainers. Just now, we've had a critical bug (https://github.com/pyenv/pyenv/issues/2367) that was happening 
with some shell setups under SSH with Bash compiled with SSH_SOURCE_BASHRC which is enabled in some Linux distributions (notably, Debian-based).
(Basically, a recently-added nested `bash -c` call was misbehaving, only under those specific circumstances.)

Now, the behavior of that compilation option is rather questionable and I'm not defending it.

However, the distro maintainers' decision to enable it looks like a workaround for the fact that sshd does not provide a way to run the 
standard shell startup files when running noninteractive commands. This makes `ssh user at host <command>` rather useless because the <command> 
would run in an incomplete -- and most importantly, different -- environment than a usual shell command, leading to all sorts of surprising 
breakage and counterintuitive behavior.

Sshd does provide `~/.ssh/rc` as a replacement -- but it's run with `sh` and separately from the main shell -- which disallows using 
shell-specific functionality like installing shell functions. (That is important. E.g. Pyenv requires a shell function installed to use some 
subcommands.)
Having to prepend every <command> with `source ~/.bash_profile;` (that some suggest at e.g. StackOverflow) is horrible UX.
In this light, SSH_SOURCE_BASHRC does begin to look like a lesser evil...

I see two ways to fix this underlying problem and hopefully eliminate the need for workarounds like that.

1) Run noninteractive shells as login shells just like interactive ones (e.g. `bash -lc` instead of `bash -c`).
This seems to be the most logical and straightforward way. In fact, I don't quite see why there had to be a difference in the first place.
(My guess is that this was a compatibility measure because at the time, existing shell startup files weren't written with noninteractive 
login shells in mind, e.g. printing stuff like motd unconditionally.)

2) In addition to `~/.ssh/rc`, source `~/.ssh/<shell>rc`, and do that in the main shell. This would allow distro maintainers to provide a 
stock file as part of a shell installation that could call standard startup files or anything else as needed.

-- 
Regards,
Ivan