SystemFile should use Static Constructors

[HEIC to JPEG]

Issue
Async operations cannot be performed in the constructor, this prevents some scenarios such as using the file picker, or automatic construction of a known type, for example "Temp File"

Reason
The file target (path, fileinfo, etc.) are not always known. For example, get me a temporary file, or ask the user to select a file using the file pickers. In those scenarios the developer has to rewrite boiler-plate code.

Proposal
Use static constructors as a standard.
var x = SystemFile.FromPath(path);
var x = SystemFile.FromFilePickerAsync(startingPointAndOptions);
var x = SystemFile.FromTempFileAsync();
var x = SystemFile.FromFolderPickerAsync(startingPointAndOptions, filename);

This adds potential for special cases in the future:
var x = SystemFile.FromPath(path, validateExistance, CacheCoreAttributes, etc);

[Arlo]

The proposed code suggests adding static methods to SystemFile that constructs an instance. Some notes on each:

FromPath

FromPath is functionally equivalent to using the normal constructor, we don't need that method.

File/Folder pickers

We won't standardize file/folder pickers until much later, maybe not at all. This is not exposed in System.IO because it implies a user interface. Instead, underlying platform APIs such as Windows.Storage, System.Windows.Forms, and Microsoft.Win32 should be used.

Helper for temp file

Having a helper to create a random temp file is a decent idea, but I have some concerns.

• If we can't standardize something, then the consumer should do it via the underlying library to minimize effort needed to implement and maintain the feature.
• This is something that should be standardized, instead of only existing on one implementation.
• It's not possible to make a contract for static methods, without using a source generator to add custom diagnostic errors.

Most importantly, this is already pretty easy to do:

var randomFile = new SystemFile(Path.GetTempFileName());