Make AsSpan(this string) ForceInline to be on par with AsSpan(this T[])

[jkotas]

Fixes #17366

[stephentoub]

Did you mean to add it to this overload? I ask because it looks relatively bulky and you didn't annotate the corresponding string/int AsSpan overload.

[jkotas]

This is trying to fix another non-nonsensical perf shard that we have today:

     char[];
     new Span<char>(a, 1 ,1); // Fastest: ForceInlined
     a.AsSpan(1,1); // Slower: ForceInlined, but the extra layer leaves collateral damage that the JIT is not able to get rid of 
     a.AsSpan(1); // Slowest: Not inlined

I agree that it is not obvious whether forceinlining this one is a good trade-off. We should be consistent at least - I will mark the string/int AsSpan overloads as well for consistency.

[ahsonkhan]

Interestingly, the portable span AsSpan overloads are all marked with this attribute:
https://github.com/dotnet/corefx/blob/master/src/System.Memory/src/System/MemoryExtensions.Portable.cs#L299

[ahsonkhan]

Orthogonal to this PR: We should consider creating an internal static Create method on Span (in Span.Fast.cs) just like the portable span and move this AsSpan method into MemoryExtensions.cs with the rest of the overloads (since the implementation between the two would be the same).
https://github.com/dotnet/corefx/blob/master/src/System.Memory/src/System/Span.Portable.cs#L48
https://github.com/dotnet/corefx/blob/master/src/System.Memory/src/System/MemoryExtensions.Portable.cs#L20

[jkotas]

I do not think this is a good idea. These extra layers make the JIT work harder and tend to leave inefficiencies behind. We should not be de-optimizing fast Span just so we can share a few more lines with the slow Span.