Configuring CI to run in 4 configurations:
 - xcode 14.3.1, iPad Air (5th generation), iOS 16.4
 - xcode 14.3.1, iPhone 14, iOS 16.4
 - xcode 15.4, iPad Air (5th generation), iOS 17.5
 - xcode 15.4, iPhone 15, iOS 17.5

As part of this change, the CI script was updated to only run the
extra validation of the examples folder one one of the 4 shards.

This removes Carthage from the README as being officially supported.
I'd guess that is generally not being used. The CI script hasn't worked
since Xcode 12.

* AccessibilityIdentifierTests tests

Fix `testEnteringTextIntoViewWithAccessibilityIdentifier` flaking

We're trying to tap on `Select All` while it is still being animated into view. The problem is two-fold:

1. The `longPress` action doesn't wait for animations to complete, it just uses a hardcoded .5s before
starting the next action.
2. Even after switching to use `waitForAnimationsToFinish`, the timeout defaults to .5s as the max to
wait for animations to complete.

To fix this, I switched `longPress` action to use `waitForAnimationsToFinish` and I upped the
default timeout to wait up to 2s for animations to complete. This seems to work much more reliably now.

* SystemTests.testMockingOpenURL

NSURL no longer parses '423543523454://', use a different protocol that starts with characters

* ExistTests

Wait a bit longer for the view controller presentation to complete

* TypingTests

In TapViewController, avoid race condition in resigning first responder and becoming first responder.
CI was flaking with a failure where "Deleted something., world" was found in the greeting text field.

* PullToRefreshTests

Leverage 'usingCurrentFrame' so we're not scrolling the table view around
while the UIRefreshControl is spinning, which immediately halts the refresh
spinner. Also, make sure that we're scrolled to the top of the test suite VC,
as otherwise the pull to refresh action might fail.

It doesn't really make sense that the default animation wait time
is the same as the stabilization time. This effectively means the
behavior of scanning the UI hierarchy for animations in progress is
never utilized for most tests out of the box.

For what its worth, we've used a 2s animation wait time and .1s
stabilization time as our defaults for a very long time.

This should generally not slow down any tests if there weren't any
animations in progress. If there were animations in progress, this
is probably a worthwhile tradeoff to make things more reliable. This
can still be configured globally to be overidden.

As part of this change, use `waitForAnimationsToFinish` in place of
a static .5s sleep for the `longPress` action.

There will be a followup PR kif-framework#1301 that should speed up some scenarios
where we're waiting longer than desired for animations to complete.

Have the pullToRefresh action pull from 25% of the way down the element to 75% of the way down, instead of pulling from the center and pulling a full height of the element

This removes the `KIFFramework` target and its consumer tests. They don't
interop well with the way that angle and quote imports work in SPM. More info:

https://joesusnick.medium.com/swift-package-manager-with-a-mixed-swift-and-objective-c-project-part-2-2-e71dad234e6

Took this opportunity to remove the spaces in the target names for the 'Testable Swift'
target, in case that was causing issues somewhere.

Two changes:
* We won't recurse into layers that are hidden
* We don't count animations that run for longer than 1 minute

Credit to @amorde for finding this