[release/9.0-staging][iOS][globalization] Fix IndexOf on empty strings on iOS to return -1

[matouskozak]

Manual backport of #111898.

Fix incorrect return condition for iOS IndexOf implementation and add test case for IndexOf("", <something>) and "".Contains(<something>). Clean-up of some styling issues and adding comments.

Customer Impact

• Customer reported
• Found internally

Customers using CompareInfo.IndexOf or string.Contains APIs on empty source strings involving ICU logic are returning a result 0 (indicates found at index 0) instead of -1 (indicates not found).

Some of the issues reported by customers:

• string.Contains returns wrong result on net-ios with .net 9 #110609
• Incorrect behavior of string.IndexOf in different cultures #111340

Regression

• Yes
• No

The regression was introduced in #86895 and initially limited to when hybrid globalization is enabled. However, in .NET 9, we switched fully to Apple native globalization APIs (initially also referred to as hybrid globalization), thus spreading this issue to all iOS Globalization code using the IndexOf API.

Testing

Previously there were no test cases for this code path. This PR adds test scenarios for both CompareInfo.IndexOf or string.Contains.

Risk

Low

This change is correcting previously incorrect behavior. It is unlikely that .NET 9 iOS customers are depending on this new behavior as it is fundamentally incorrect as per .net doc.

[matouskozak]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jeffschwMSFT]

lgtm. we will take for consideration in 9.0.x

[matouskozak]

/ba -g the timeout on CoreCLR Windows x64 Debug is not related to this change

[matouskozak]

/azp run runtime-extra-platforms

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[matouskozak]

I had to disable the newly added test for wasm hybrid globalization due to an incorrect output 551ba2e (fyi: @ilonatommy) Rerunning the CI to confirm there is nothing else related. @jeffschwMSFT

[matouskozak]

The timeouts on osx-arm64 Release NativeAOT* jobs are not related and are already present on rolling-builds, e.g. https://dev.azure.com/dnceng-public/public/_build/results?buildId=947948&view=results.

[matouskozak]

The runtime-extra-platforms failures are not related to this PR.

[matouskozak]

/ba-g timeouts are not related to this PR