Use ordinal string comparison in string manipulation methods

[auduchinok]

Use overloads with StringComparison parameter where CurrentCulture would be used instead.

[auduchinok]

@dotnet-bot test Windows_NT Release_fcs Build please

[dsyme]

Just requesting a change to use StartsWithOrdinal etc. extension methods, thanks :)

[dsyme]

Could you add StartsWithOrdinal/EndsWithOrdinal extension methods to illib.fs? Then it's easy to search and remove uses of StartsWith

[auduchinok]

Done.

[dsyme]

I don't really know what comparison resource and assembly names should use. My understanding is that it doesn't actually make a difference if the thing being compared with is ASCII

[KevinRansom]

@dsyme

assembly names are case insensitive, however guidance is that they should be treated as though they were case sensitive. (Which is pretty scary to me.)

So StringComparison.Ordinal conforms to best practice for assembly names.

https://docs.microsoft.com/en-us/dotnet/framework/app-domains/assembly-names

Note
The runtime treats assembly names as case-insensitive when binding to an assembly, but preserves whatever case is used in an assembly name. Several tools in the Windows Software Development Kit (SDK) handle assembly names as case-sensitive. For best results, manage assembly names as though they were case-sensitive. 

ResourceManager is configurable:

if ignore case is false, then does Culture sensitiveComparison, if ignore case is true does InvariantCulture lookup.

https://docs.microsoft.com/en-us/dotnet/api/system.resources.resourcemanager.ignorecase?view=netframework-4.7.1#System_Resources_ResourceManager_IgnoreCase

Remarks
If the value of the IgnoreCase property is false, a resource with the name "Resource" is not equivalent to the resource with the name "resource". If IgnoreCase is true, a resource with the name "Resource" is equivalent to the resource with the name "resource". Note, however, that when IgnoreCase is true, the ResourceManager.GetString and ResourceManager.GetObject methods perform case-insensitive string comparisons by using the invariant culture. The advantage is that results of case-insensitive string comparisons performed by these methods are the same on all computers regardless of culture. The disadvantage is that the results are not consistent with the casing rules of all cultures. 
For example, the Turkish alphabet has two versions of the character I: one with a dot and one without a dot. In Turkish, the character I (Unicode 0049) is considered the uppercase version of a different character ı (Unicode 0131). The character i (Unicode 0069) is considered the lowercase version of yet another character İ (Unicode 0130). According to these casing rules, a case-insensitive string comparison of the characters i (Unicode 0069) and I (Unicode 0049) should fail for the culture "tr-TR" (Turkish in Turkey). However, because the comparison is conducted by using the casing rules of the invariant culture if IgnoreCase is true, this comparison succeeds. 

[KevinRansom]

If the guidance in that page for resources is correct, then Culture Sensitive is the way to go for perf and working set.

[KevinRansom]

What I mean is, if the look up is going to be CultureSensitive in the resource manager, which it is, I don't think we set ignoreCase. I don't know whether A StringComparison.Ordinal check elsewhere can introduce bugs, my intuition is that it won't … but I truly don't know.

[KevinRansom]

looks good.

[auduchinok]

@dotnet-bot test Windows_NT Release_ci_part2 Build please.

[abelbraaksma]

@KevinRansom I think you meant CultureInsensitive? Because that's the only way resources are read the same way on all systems. And i think that's what the guidance you referenced suggests there.

Changing that default may lead to builds failing on one system and succeeding on another (for instance, my build servers are in Germany and I develop in The Netherlands, I use resources a lot, marking the default Sensitive would possibly introduce hard to diagnose errors)