API Suggestion: Additional time format pattern for concise ISO8601 format

[Tornhoof]

The following applies to DateTime, DateTimeOffset and UTF8/UTF16.
Motivation
Currently the time format pattern 'O', 'o' is the roundtrip pattern and the output of a formatted string looks like 2009-06-15T13:45:30.0000000Z and quite often more like 2009-06-15T13:45:30.0000000-00:00. This is great for formatting, but the pattern specifies 7 fractional digits in a 100ns precision, this makes live complicated if the date format is produced by another programming language.
According to https://nbsoftsolutions.com/blog/iso-8601-and-nanosecond-precision-across-languages python has 6, rust has 8, Go has 9 fractional digits.

I propose another format pattern, let's name it 'i' for discussion, which is basically the same as 'o' just with a relaxed requirement of fractional digits.

Formatting
Like 'o', but:

• If the ticks are zero then omit them (e.g. above example would be 2009-06-15T13:45:30Z)
• Print 'Z' in all cases if the timezone is UTC (which currently not consistent over all of the different datetime/utf variants)

Parsing
Like 'o', but:

• Allow an arbitrary amount of fractional digits and ignore the digits after 7 digits.

Side effects:

• A new format pattern should not affect existing patterns (I assume changing an existing pattern is a breaking change)
• Performance needs to be evaluated as a non-fixed amount of fractional digits takes a bit more time, the relevant code more or less already exists for Timespan

Intended Audience:

• Everyone writing code parsing/formatting ISO8601 Datetimes for roundtripping with other platforms. Example: @ahsonkhan will probably need it for his JsonReader/Writer currently in corefxlab.

Alternatives:

• Do not implement the formatter side, just modify the 'o' parser side to allow for a different amount of fractional digits, then no new pattern is necessary, but we still write a rather
• No new formatter pattern, but instead extension methods and using the internal structures of the respective formatters/parsers.
• Put it into an extra lib, but as >90% of the code overlaps with the formatters/parsers of 'o', 'o' is at the end only a special case of 'i'

[Tornhoof]

@ahsonkhan You might want to tag this regarding your JSON Parser, this will affect the interoperability of DateTime/DateTimeOffset with other programming languages.

[Clockwork-Muse]

Also common - Java has 9 digits (full nanoseconds precision).

Although it's actually possible to parse an unlimited number of digits via TryParse.
The problem with some of the existing implementation, as I bring up in dotnet/corefx#32907, is that the parsing ends up rounding up, meaning anything with 999999999 ns ends up bumping up to the next second. Which means that you're silently bumping objects into the next "bucket". Which has to be throwing somebody off.

[chucker]

See also #9364

[joperezr]

cc: @tarekgh