Override Span-based Read/Write on FileStream

Override Span-based Read/Write on FileStream

Adds overrides for the new Span-based Read/Write methods on FileStream.

A few notes:
- As with {Unmanaged}MemoryStream, FileStream isn't sealed, which means a derived type could have overridden all of the existing abstract/virtual methods, including Read(byte[],int,int).  If a consumer then switched to using that stream with Read(Span), because we now override Read(Span), the consumer should get the same behavior intended by the stream developer. As such, since we have no good/efficient way to check whether Read(byte[],int,int) is overridden, we check whether the current stream is a concrete FileStream (rather than a derived type), and if it isn't we use the default base behavior, which will call the Read(byte[],int,int) method.
- FileStream is odd in that it has a dual nature around whether it was initialized for sync vs async, a setting that on Windows ends up configuring the native handle to operate in async mode.  Sync operations on an async-configured FileStream end up delegating to the async methods and blocking, and async operations on a sync-configured FileStream end up using the synchronous behavior asynchronously.  There were some inconsistencies around how this was handled between Windows and Unix, in particular around the ReadByte method, and as part of adding these overloads, I changed that as well, as doing so made the code simpler with the new Span-based support.  Technically this is a breaking change on Unix, but it would be very niche, including calling ReadByte on an async stream while other async operations were in progress... in that case, the desktop and Windows core behavior was to allow direct access to any cached data in the buffer, whereas on Unix we would serialize the ReadByte call with other async operations in flight.

Commit migrated from https://github.com/dotnet/coreclr/commit/1cb3580858f3224f0e0981965a2da1fd61ba9e08