Make Sys.which return nothing instead of throwing

[ararslan]

Currently Sys.which("prog") will throw an error if prog is not found or is found but is not executable. This changes the function to instead return nothing in those cases, thereby simplifying logic for situations such as hierarchically choosing an executable based on which in a list is present.

Fixes #27284.

[staticfloat]

This is good, but I echo @StefanKarpinski's thought that we should do something special when you try to interpolate $(nothing). Unfortunately, it looks to me like the way `$(nothing)` gets parsed is that the @cmd macro gets a string; which means that the nothing -> "nothing" translation is being done before we can even specialize on the fact that this is a Cmd that is being constructed, not a String.

If there's some way for us to specialize, I think it would be nice to do one of two things:

• Allow the buildup of Cmd's with nothing in them, but cause nothing to map to an empty string; e.g. `/bin/foo $(arg1) $(arg2) $(arg3)` could become /bin/foo "--arg1" "" "--arg3". In the case of cmd.exec[1] being an empty string, we would, of course, throw an error upon run(cmd), which would address the concerns of trying to do something like `$(Sys.which("foo")) --help`, and the Sys.which() call returning nothing.

• Disallow the buildup of Cmd's with nothing in them at all. E.g. somehow, at @cmd time, throw an error if any of the arguments being spliced in evaluate to nothing. This feels a little dirty to me, but I'd argue it's better than what we do now.

If we do nothing and leave this as is, I guarantee there will be questions about why $(Sys.which("curl")) gives an error that sounds like Julia is picking up 90's kid slang; ERROR: could not spawn `nothing`

[staticfloat]

The changes as they are look good, but let's figure out what we want to do with `$(Sys.which("foo"))`

[StefanKarpinski]

The latter option (throw an error) seems like the clearly correct choice to me. If you want to splice in an empty string, use an empty string. If you ended up with nothing that means there's a problem (e.g. a program could not be found) and you should get an error.

[JeffBezanson]

It's possible it should also be an error to pass nothing to print or string --- you'd have to use repr. Otherwise a similar problem would arise in other contexts.

[StefanKarpinski]

I do think that's the most principled solution.

[ararslan]

So I guess this is 2.0 material now that 0.7-alpha is tagged?

[Keno]

Meh, we can sneak in a couple of things between alpha and beta. This won't be the only thing and it only affects a rather rarely used API.

[mbauman]

Maybe we can sneak this in during the alpha period?

[ararslan]

Should the nothing behavior in string et al. be addressed before this is merged? I don't know that I'll have time to get that figured out soon.

[staticfloat]

I say we merge this, and continue `$(nothing)` -> error() discussion in a separate issue.

[staticfloat]

Issue opened here: #27352 and with that I'm going to merge, as this is an improvement on a change that didn't even exist in 0.6, so it's not even really breaking. ;)