Recombine FileStream to simplify and avoid bugs

[stephentoub]

FileStream in corefx is currently implemented as a wrapper around an inner stream that actually provides the logic for the current platform, e.g. it wraps a UnixFileStream on Unix, a Win32FileStream on Windows, etc. This has several issues:

• Adds expense to create, as we're now creating two streams where we actually only need one
• Adds expense on every operation, as each virtual call on the FileStream then turns around and calls a virtual method on the wrapped stream
• Leads to bugs, e.g. it looks like we currently have a bug, where in sync mode, FileStream.ReadAsync calls Win32FileStream.ReadAsync which calls base.ReadAsync which in turns queues a work item to call Read... but it's calling Read on the inner stream, not on the outer stream, which means a FileStream-derived type that overrides Read won't have its override called.

We can avoid all of these issues by recombining FileStream into a partial class like we use elsewhere in corefx. The primary trickiness comes with WinRT, where, depending on the path, we sometimes use Win32FileStream and sometimes use WinRTFileStream.

cc: @ericstj, @justinvp, @JeremyKuhne, @ianhays

[ianhays]

+1 great idea. I'm really not a fan of the Win32FileSystem/UnixFileSystem structure either. The "Current" FileSystem variable seems like unnecessary indirection when we could just be using partial classes with conditional inclusion instead.

[ericstj]

The FileSystem PAL we have today predates all of the cross-plat work and was designed primarily for the WinRT sceanario (and potentially even public exposure). Now that we have a more common pattern for x-plat and cross-compiling and we're cross-compiling anyway it makes sense to remove this abstraction.

[JeremyKuhne]

I'm good with this as well.