Fix objc transition for cc_binary -- smallest change

[cpsauer]

A quick cut at the smallest change that would fix #19204.
Please see that issue for context.

#19236 is an alternative that attempts to simplify. It's a slightly larger--and much redder--CL.

[keith]

doesn't CPU always have a value that would start with darwin? (unless you explicitly specified otherwise) as in if you passed --macos_cpus=arm64,x86_64 --cpu=darwin_x86_64 it should build a fat binary for both archs but with this change I don't think it would?

[cpsauer]

Hey Keith! Good Q. Glad I get to engage with you on this.

Here's my reasoning--and I'd love it if you'd check me. Two cases:

1. Built under a rules_apple top-level/binary target -> same fat binary behavior as before
   Why? binary target does split cpu transition on e.g. --ios_multi_cpus or --macos_cpus -> triggers picking up the CPU from apple_split_cpu in the first lines of this function, _determine_single_architecture, returning early and bypassing all the if statements around this diff.
   Hence no change; you still get your fat binary with architectures controlled by, e.g., --macos_cpus.
2. Not configured to be built as a fat binary by a higher-level rules_apple target -> we're traversing these cases, trying to determine an architecture to fall back on.
   Current bazel behavior is, I believe, producing a single-arch archive (sometimes w/ the wrong architecture), rather than a fat binary. That's what I'm seeing in testing, and also what I'd expect from the existing code; it's only returning a single CPU.
   (Now, like you, I'm not so sure the current behavior is ideally intuitive, but that's a different issue--and not one I'm trying to tackle with this intentionally minimal fix, doubly since incoming transitions like this are constrained to be 1:1 and Bazel's general binary-vs-library MO.)

To sum the above: I think we have have the same fat binary behavior as before.

(What this does change is, in the single, thin output case, where we hit this code and aren't honoring multiple cpus anyway, which architecture gets chosen as a fallback. The change makes bazel honor the single cpu flag, whether defaulted to the current machine, configured, or specified on the command line (unless the cpu has been set to some obviously invalid value that's not for Mac (doesn't start with darwin), at which point we go down the fallbacks as before). Goal here was minimal change that made objc_library work correctly with the core cc-ecosystem while maintaining reasonable defaults and configurability for the other common use cases.)

[cpsauer]

Closing because Keith's #19256 (merged) puts us on the path to remove the problematic transition entirely. See #16870