Fix 8+ fractional digit checking (TimeSpan.Parse)

[pengowray]

Fixes: #33577 TimeSpan.Parse gives inconsistent and incorrect results with 8 fractional digits.

InvalidFractionTest() is the culprit. It fails all the same things I was failing before. Adjusted code passes all the tests I can throw at it. Simply an off-by-one error (which becomes an off-by-ten error thanks to logarithms).

TimeSpan.Parse has some fairly convoluted logic when it gets to IsInvalidFraction(). It attempts to reconstruct the number of fractional digits in a TTT token based on the number of leading zeroes and the integer number itself, or rather, it avoids reconstructing it, and just attempts to check if there's not too many digits, involving the largest possible number, divided by 10 or 100 etc depending on the number of leading zeroes. It was getting this wrong by 10 or by one digit, which meant it was falling back onto some weaker checks earlier in the code. These gave very odd results (e.g. different results for numbers ending in 99 and 98)

This patch fixes that very simply.

I've created an InvalidFractionTest in my own repo to test the code against all the cases I could think of, but I haven't attempted to integrate the Unit Tests into corefx's codebase. This patch just has the fix itself. So I assume you'll want some tests before committing.

[danmoseley]

Thanks @Quole . Yes, please let's include tests as part of the commit.

[jkotas]

This is change in CoreLib. It should be submitted via CoreCLR repo. This PR can be re-purposed to have test only.

[jkotas]

The details are explained in https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/adding_new_public_apis.md. The doc talks about adding new APIs, but it applies for bug fixes in the existing APIs as well.

[stephentoub]

dotnet/coreclr#21077 is for the product change, and #33925 is addressing tests, so closing this one as a dup.