Add IStorageProvider implementation based on IFileProvider

[ronaldbarendse]

This PR builds upon #11 (comment).

Instead of wrapping the media IFileSystem (Umbraco's read/write IO abstraction) as an IFileProvider (ASP.NET Core read-only IO abstraction) to then use in the StaticFileMiddleware, this directly implements the IFileProvider for the read-only part and exposes the write-operations in a new IStorageProvider abstraction.

This is a POC and still needs a lot of work!

[ronaldbarendse]

These are just some idea's that came up recently related to reworking the file providers:

• Add support for getting (generating/storing) and validating file hashes: this can be used when comparing files, e.g. as part of a deployment and in the case of Azure Blob Storage the MD5 hash can already be retrieved from the blob properties;
• Instead of getting a boolean result from the move/copy/delete actions, return more context (e.g. to differentiate between a failed move, because a non-overwriting and non-recursive move found either subdirectories in the source or an existing file in the destination). This could be done using result enums, by throwing a custom exception (and possibly implement Try* methods) or something similar/identical to the CMS Attempt/OperationResult;
• Add async versions of the IFileProvider methods: GetDirectoryContents and GetFileInfo;
• Create a base wrapper implementation that accepts an existing IFileProvider, so we can e.g. make PhysicalStorageProvider inherit from the StorageProviderBase class and accept a PhysicalFileProvider (instead of having to inherit from this class).

[EelmanE]

Any chance this will continued? It seems related with an performance issue several users are experiencing in different versions of Umbraco (including 15).