BUG(?) Missing-values in RandomForest only during inference time shouldn't send missing-values to the child with most samples

Currently, when missing-values occur only in the testing dataset for constructing a RandomForest, there is a policy that the missing values are sent to the child with the most samples. This amounts to in some sense imputing the missing-value data using the data in the child with the most samples. An issue here is that this may bias the tree prediction towards say a class in the training dataset with more samples. 

For example, say there are 1000 training samples of class 1 and 10 training samples of class 0, and then during test time there are some NaNs. The predictions would then bias towards class 1, whereas it should really be uninformative because the NaNs during test time are treated as missing completely at random.

## Proposed Solution

However, an alternative and more sensible strategy is that when NaNs are not enountered during training, but show up in testing data, they should just be sent stochastically down the tree using weights:

- `p_left_child = n_left_samples / (n_left_samples + n_right_samples)`
- `p_right_child = n_right_samples / (n_left_samples + n_right_samples)`

This ensures that there is no bias towards the class "with more samples". This can be implemented by allowing the value of `missing_go_to_left` (https://github.com/scikit-learn/scikit-learn/blob/6bf0ba5257d55ea0f3c89d7c4762096d84c052cc/sklearn/tree/_splitter.pxd#L28) to be `2`. If the value is `2`, it implies that missing-values were not observed during training time, and thus should be stochastically set.

Overall, it's a very simple change, and I can also implement relevant unit-tests.

cc: @thomasjpfan who implemented the original missing-value support in RandomForest.

## Related
xref: This policy will also impact #27966 and #28268 

This is also an issue in other estimators that handle NaNs: https://scikit-learn.org/stable/modules/ensemble.html#missing-values-support

COMMENT:
I imagine there is some overhead due to the potential to query a RNG many times. Tho this would potentially be also an edge case since it implies there are many missing-values seen during test that were not seen during training. I.e. the only times we would stochastic process left/right is when a specific feature is used that does not have missing values encountered for that specific tree's node depth in the training data. I personally think this edge-case is less worrisome than the bias point I raised, but it's plausible to occur in practice of course.

I think the situation you describe is a good one tho and makes the point that the situation may be more complex. It is presumable this could occur in practice tho. Some ideas:

1. We treat it like an edge-case and simply the fact that it would not come up as often as tie-breaking in nearest-neighbors and just allow stochastic processing the test data
2. We allow the user to specify such behavior during training time, so that way `missing_go_to_left` can be set accordingly if there are no missing-values encountered.
3. We allow the user to specify such behavior during runtime. I'm unsure how we could best implement this behavior tho, so would have to take a look at the code.

Labels: Needs Investigation