Fix: OSS builds can accidentally using coreutils cp

[blakef]

Summary:
There are two places where we use a feature specific to the system version of 'cp', the:

-X Do not copy Extended Attributes (EAs) or resource forks.

This feature isn't available in GNU's cp, which is commonly installed on macOS using:

brew install coreutils && brew link coreutils

We can avoid the problem alltogether by being specific about the path of the system cp.

Changelog: [General][Fixed] don't break script phase and codegen when coreutils installed on macOS

Differential Revision: D56143216

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D56143216

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D56143216

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	19,385,256	-13
android	hermes	armeabi-v7a	n/a	--
android	hermes	x86	n/a	--
android	hermes	x86_64	n/a	--
android	jsc	arm64-v8a	22,760,259	-6
android	jsc	armeabi-v7a	n/a	--
android	jsc	x86	n/a	--
android	jsc	x86_64	n/a	--

Base commit: 7047563
Branch: main

[facebook-github-bot]

This pull request has been merged in e079953.

[github-actions]

This pull request was successfully merged by @blakef in e079953.

^{When will my fix make it into a release? | How to file a pick request?}

[isaacl]

Although this PR is reasonable, the description of what it fixes is inaccurate.

This never affected users who simply ran brew install coreutils && brew link coreutils. This is because of the caveat on the formula:

==> Caveats
Commands also provided by macOS and the commands dir, dircolors, vdir have been installed with the prefix "g".
If you need to use these commands with their normal names, you can add a "gnubin" directory to your PATH with:
PATH="/opt/homebrew/opt/coreutils/libexec/gnubin:$PATH"

In short, this only affects users who have manipulated their PATH variable to put gnu tools higher than the OS X standard tooling. I'm sure there's all sorts of similarly weird and dangerous environment changes I could make which would break XCode or the react-native build...

So while this patch is safe, I'm not sure RTN should be accepting patches like this. They adds complexity to the project and every PR has a risk of introducing regressions or derailing a release. All for the meager gain of building better on an incorrectly configured computer.