build: macOS package notarization

Works locally, and I can cleanly install .pkg's created by this on Catalina, but there are some things we need to sort out before it can be deployed:

• NOTARIZATION_ID in the ci-release job to (1) signal that notarization is required after .pkg creation and (2) point to the correct Apple ID.
• An AC_PASSWORD entry in the Keychain on the release machine(s) for the Apple ID identified by NOTARIZATION_ID (xcrun altool --store-password-in-keychain-item "AC_PASSWORD" -u "<appleid>" -p '<password>' (I'm documenting this in nodejs/secrets and I think there's another place we have release machine docs in nodejs/build). (giving up on keychain, see https://github.com/nodejs/build/pull/2199).
• Xcode 11 on our release machines - we're going to have to bump everything to 11, even for Node 10. In the process we probably may as well ditch older release machines (we're still using 10.10 and 10.11 but are working on more modern machines). There's some risk involved in this but I think Build is mostly in agreement that it's minimal.
• A patch to gon, the tool I'm using here to handle the messy bits of the notarization process. Unfortunately we have an unsigned executable inside our packages, /usr/local/lib/node_modules/npm/node_modules/term-size/vendor/macos/term-size, used by a dependency of a dependency of npm's. Apple reports this as an "issue" but still notarizes the package. gon treats all issues as fatal because this can mean the package isn't installable (see https://github.com/mitchellh/gon/pull/6), but in our case, my testing suggests that this isn't a problem at all, I think because it all ends up being command-line applications anyway. I have a proposal @ https://github.com/mitchellh/gon/pull/14 (which is used here, "ignorable_path_issues") but we'll see how that goes.

Includes @gdams' hardened-runtime patch from https://github.com/nodejs/node/issues/29216#issuecomment-546932966

@nodejs/build @nodejs/platform-macos

Ref: https://github.com/nodejs/node/issues/29216