src: fix FIPS init error handling

[tniessen]

If --enable-fips or --force-fips fails to be applied during ProcessFipsOptions(), the node process might exit with ExitCode::kNoFailure because ERR_GET_REASON(ERR_peek_error()) can return 0 since ncrypto::testFipsEnabled() does not populate the OpenSSL error queue.

This is problematic because an exit code of 0 (i.e., kNoFailure) indicates successful execution of the node command, even though it already failed during initialization. (Error messages also appear to be broken, but fixing that is not as urgent as not pretending that the command succeeded.)

For example, if a user invokes node from within a bash script and NODE_OPTIONS includes --force-fips, the execution of the command will appear to have succeeded even if the actual user script was never executed due to a configuration error.

You can likely test this locally by running

./node --enable-fips ; echo $?

with the current node binary from the main branch if compiled without support for FIPS.

As confirmed by the XXX comment here, which was added three years ago in commit b697160, even if the error queue was populated properly, the OpenSSL reason codes are not really related to the Node.js ExitCode enumeration.

This commit changes the initialization logic to exit with kGenericUserError in this case, since such errors are most likely due to incorrect configuration. It also modifies the existing test case to actually check the exit code of the process, which would have prevented this recent regression.

Considering that the current behavior is incorrect, I'd prefer to merge this as a bugfix rather than a semver-major change.