avoid non-portable "which" to detect installed programs
    
    The "which" utility is not guaranteed to be installed either, and if it
    is, its behavior is not portable either. This means that when various
    programs are installed, the which check will report a fatal error
    because the which tool did not exist and the shell returned a nonzero
    status when attempting to fork+exec. If it did exist, it might not be an
    implementation of which that returns nonzero when commands do not exist.
    
    The general scripting suggestion is to use the "command -v" shell
    builtin; this is required to exist in all POSIX 2008 compliant shells,
    and is thus guaranteed to work everywhere.
    
    For some in-depth discussions on the topic, see:
    
    - https://mywiki.wooledge.org/BashFAQ/081
    - https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250
    
    Examples of open-source shells likely to be installed as /bin/sh on
    Linux, which implement the 15-year-old standard: ash, bash, busybox,
    dash, ksh, mksh and zsh.
    
    Several Linux distros which do currently ship a (decent quality) which
    utility in their default install are looking to get rid of it:
    
    - Gentoo: https://bugs.gentoo.org/646588
    - Debian: https://lwn.net/Articles/874049/
    
    In this case, we know that "install" exists. If it doesn't, the Makefile
    abnormally aborts, since $(INSTALL) expands empty and `make install`
    fails. Anyways, it is installed by coreutils.
    
    There's no point in converting it to an absolute path inside a Makefile
    invocation. The only reason it is a variable at all is so that users can
    override it. The only thing setting it to the value of running (on every
    single make) a subprocess for $(shell which install) *does*, is
    potentially mess up when this arbitrary dependency isn't available.
    
    Just default to calling it without a path.
    
    Signed-off-by: Eli Schwartz <eschwartz93@gmail.com>