fix: unexpected behaviour of akwhere with arrays containing nones

[tcawlfield]

There is a problem with ak.which (the three-argument version) where if both (1) a conditional array element is optional yet True/False, and (2) the array element NOT selected by the condition is optional and None, the resulting element will be None regardless of the value that ought to have been selected.

[jpivarski]

This is good! We talked about the refactoring of how broadcast_any_option_akwhere is dispatched, and I see that it has been updated.

The print statements, even though they're commented out, should be removed; just accept all the suggestions below.

Also, update this to main and re-run the tests. Then if everything passes, it can be merged.

Actually, regarding that: in our other PRs, the MacOS tests have been failing because GitHub removed MacOS 11 and the newer versions of MacOS have been compiling/linking code that can't be loaded. (Talk to @ianna if you have any ideas.) Is your PR really passing all of those tests? If it fails to pass after you've updated, maybe that's a hint as to what's going wrong: it might be subtly in one of the new GPU kernels, or something that was touched to add those GPU kernels (MacOS does not compile the GPU code itself, but it might have been affected in some unexpected way).

If, after updating to main, you see errors, then this PR will be approved for merging, but can't be merged until the MacOS errors are fixed. @ianna and I have talked, and we're considering temporarily turning off the tests that fail on MacOS so that PRs aren't blocked, but we can't make a release with that because it will break Uproot. (Uproot depends on the code that's failing to load.)