Because we don't know if mac BSD cp or GNU cp will be first on the path,
where there is ambiguity (e.g. with -R flag), we will use the macOS cp
command in /bin to ensure that we have consistent results. The
alternative would be to fixup each instance of the cp parameters so that
they work consistently with either cp command, but given these scripts
can run only on macOS, that seems unnecessary.
This replaces the earlier change in 97c6331b5.
Fixes#8533 after build agent maintenance put GNU coreutils cp on path
ahead of macOS /bin/cp. This subtly changed the behaviour of the `-R`
flag such that it copied the folder into a subfolder rather than copying
the contents of the folder into the destination folder:
Original layout:
```
Install Keyman.app/Contents/MacOS/
applet
textinputsource
Keyman.app/
```
Corrupted layout:
```
Install Keyman.app/Install Keyman.app/Contents/MacOS/
applet
textinputsource
Keyman.app/
```
Query: should we be rolling back the path changes so that /bin is first
on the path? I am concerned about other subtle changes in behaviour in
the macOS and iOS builds. Otherwise it feels like we may need to audit
the scripts in /mac, /ios (and possibly /common, /core, /web,
/resources) for potential changes.
Annoyed that it took me so long. Also annoying that macOS fails so
subtly when a parent folder has the .app extension in its name.
Fixes#7227.
We want to use keyman.com for now even for alpha builds, as
keyman-staging.com is going to be used for transition to Docker-based
hosting, and it will be problematic to try and share that process with
alpha builds.
Fixes up scripts (except under /linux) to use `#!/usr/bin/env bash`
instead of `#!/bin/bash` or `#!/bin/sh` so that we don't end up with
the ancient version of bash supplied with macOS.
This became urgent with this PR, because of bash-4.xisms in
build-utils.sh, for example on line 572:
```
if [[ -v _builder_params[$e] ]]; then
```
