FIX validate properly zero_division=np.nan when used in parallel processing

[glemaitre]

closes #27563

For the classification metrics, we make a constraint check with constraints = Options(Real, {0.0, 1.0, np.nan}). The issue is that we will check if a value is in the set with np.nan is constraints. In a single process, np.nan should be the same singleton so we don't have any issue. However, in parallel process, np.nan is apparently no the same singleton and the np.nan will not be np.nan. This is indeed the case when running on of these score function (via make_scorer) within a cross-validation loop.

This PR intends to make public the _NanConstraint via the string "nan" such that we make the right check and not the use the is statement.

[github-actions]

✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

_{Generated for commit: c76787b. Link to the linter CI: here}

[glemaitre]

ping @jeremiedbb to be sure that I don't make any mistake in the testing.

[jeremiedbb]

LGTM.

I thought that we could tweak Options to correctly handle nan detection but it does not make things simpler. This solution is simple and not confusing so let's go for it.

[glemaitre]

I thing that the failure was not linked (negative score_time), I will relaunch this specific build.