Add experimental device_and_simulator rule

[brentleyjones]

Fixes #285, #438.

This rule is experimental because it might not be the right API to enable proper device support, but it's better to get something out there so we can iterate on the support.

Also updated the multiplatform example to use the device_and_simulator rule. Of note, the //examples/multiplatform/Tool target is not included in //examples/multiplatform:device_targets, as it would generate two configurations of the same binary (because the swift_binary doesn't have the rules_apple transition). It's things like this that make me feel this API isn't quite done yet.

[brentleyjones]

Ideally we wouldn't need another rule for this, but when applying the split transition (which is needed in order to get both simulator and device builds in the same build graph) we can't see any details of the target the transition is being applied to. And we can't blindly apply the transition, because rules that don't have the rules_apple transition (mainly cc_binary and swift_binary) will get two different Starklark Transition hashes, but otherwise will be identical. This results in two versions of those binaries, and potentially all of their transitive dependencies.

Maybe there is a way, either in Starlark or generator, to detect these "no really different" configurations. Right now we could do that by seeing that the cpu portion of the bin directory didn't change, even though it has a different ST-HASH. I believe in the future that portion will go away in favor of only the Starlark Transition hash... but in the future maybe the hash won't change if the rule doesn't use those values, or we will find another way to detect that the configurations are effectively the same?

Either way, I think we should take this change as is, but think about ways to improve the UX of the API.

[brentleyjones]

Ohh, also, if a rule doesn't have a provisioning_profile set for the device configuration, then rules_apple will fail analysis. That adds another wrinkle, but possibly one we could fix on the rules_apple side (maybe a build setting that we can transition to tell it not to validate the profile, since we aren't building).

[jpsim]

Why is this set to test only?

[brentleyjones]

So it can depend on tests.