Disable rules swift VFS overlay when rules_ios VFS overlay feature is enabled.

[gyfelton]

What changed?

Not enable vfsoverlay on rules_swift side if VFS overlay feature is enabled on rules_ios side

Why this change?

On our downstream project, We found that the way rules_swift writes the VFS overlay is not compatible with rules_ios. Specifically it has overlay-relative being true where rules_ios has it being false. In rules_ios we there calculate the number of ../ needed to associate a file to a right external-content path. In vfs overlay generated by rules_swift however, it has relative path to the root of bazel-out.
While I believe this works with bazel build (otherwise CI should have been red), this apparently does not work when building with rules_xcodeproj against a pure swift library. For unknown reason indexing will have unable to locate module Foo error without overriding the overlay-relative to be false and hardcode ../ in front to make it work.
Removing this makes rules_swift provide the real path to a swift module. And this makes xcode proj able to jump a swift module interface when cmd click on a swift module inside the source file.

In addition, we found that downstream project's CI still works if we point to rules_swift that has VFS overlay implementation broken, other than one place that depend on a swift_library directly. Which means the VFS generated by it does not participate in compilation for all apple_framework targets.

Note that this is a broken change but downstream user can still enable swift.vfsoverlay on their side.

Next step:

go to rules_xcodeproj side and figure out if the integration tests with rules_ios is broken also. If so red green and try to find a way to guarantee it works.

[thiagohmcruz]

I'd appreciate if @luispadron could give us some input here, not only in what is changing but if you could spend some time verifying that this doesn't break any builds and/or IDE behaviour for you.