Improved StorageFile APIs

# Proposal: Improved file-access APIs for UWP and AppContainer

## Summary
Provide an updated version of `StorageFile` that fixes performance and usability issues in the current `Windows.Storage.Storage*` set of types. Support apps that think in terms of file paths & handles instead of StorageFile objects.

## Rationale
The current `Windows.Storage.Storage*` types are designed to give programmatic access to regular files, shell namespace items, and other Windows entities backed by files. A single abstraction over all those spaces is interesting but comes with high costs - namely performance and impedence-mismatch with existing application code. Project Reunion should clearly explain why StorageFile is important and - where possible - provide lower-level access to the user's files.

* The `BroadFileAccess` capability is "scary" to customers but required even for limited UWP scenarios.
* Many libraries and helpers take file paths instead of objects (even instead of handles)
* Apps observe serious performance costs related to using StorageFile's built in functionality
* Low-level code can access the `...FromApp` API variants, but higher-level code (JS, C#) interop for them is very limited.

## Scope

| Capability | Priority |
| :---------- | :------- |
| App has direct access to any files the user has given it using low-level APIs | Must |
| Feature exposes an object-oriented view of `...FromApp` platform APIs | Must |
| APIs in this feature are _synchronous_ after user permission is acquired | Must |
| Feature provides standard `IStream`/`ISequentialStream` APIs for these files | Should |
| App can convert between existing `W.S.Storage*` and types in this functionality | Should |
| UWPs can access Shell Namespace types directly with user approval | Should |
| APIs taking or returning StorageFile should return/accept these objects instead | Should |
| App can prompt the user for broader access without requiring an app restart | Could |
| App can access user data without user intervention | Won't |

## Open Questions

### Should UWPs be given access to the `IShell*` family of APIs?

As these APIs are not truly universal on all editions of Windows, if an app were to program against them directly the app would not work on editions like HoloLens or Xbox.

### Should Reunion warn the user about apps using this capability?

Some platforms periodically remind users that "App X is using feature Y, are you OK with that?" How should Reunion make the user aware that a "low rights" application is using capabilities?

The proposal identifies no implementation files, tests, or entry points. Start by reading the Scope and Open Questions sections, then determine the required API design, permission model, and compatibility constraints; the work is done only when those requirements are resolved into an agreed implementation plan.

Written by the indexing model from the issue text.