Implement IFileProviderFactory, move shared infrastructure to Umbraco.StorageProviders and support Umbraco 10

[ronaldbarendse]

PR umbraco/Umbraco-CMS#11783 added a new IFileProviderFactory interface that an IFileSystem can implement to expose itself to the WebRootFileProvider, that in turn is used by the StaticFileMiddleware to serve the files.

Adding support for this to the AzureBlobFileSystem has the following benefits:

• Media stored in Azure Blob Storage can be accessed using the ASP.NET Core IFileProvider abstraction, which is used by the static file middleware, Tag Helpers, etc.
• This package doesn't have to ship/maintain its own middleware:
  • AzureBlobFileSystemMiddleware is therefore removed;
  • UseAzureBlobMediaFileSystem() is not needed anymore for the same reason, simplifying setup;
  • The response headers can be configured (it previously used a fixed Cache-Control: public, must-revalidate, max-age=604800 header).
• The default IImageProvider in ImageSharp.Web v1 uses the WebRootFileProvider, removing the need for adding an additional AzureBlobFileSystemImageProvider (one minor downside is that the max-age of the original image returned by Azure Blob Storage isn't used anymore and ImageSharp falls back to the configured BrowserMaxAge setting).

Because the dependency on Umbraco was updated to 9.3.0 (the version introducing IFileProviderFactory) 10.0.0-rc1 and I've moved shared infrastructure code (the CDN media URL provider) to a new Umbraco.StorageProviders project, I've bumped to version to v2.

I've also included the changes in #34, so the build and versioning simplification can/should be reviewed and merged separately first. I've reverted the versioning changes (so we can align with the updated versioning in the CMS later), but kept the simplified build, as that doesn't require different release workflows and speeds up the build times significantly.

With this PR is merged, adding additional storage providers (like AWS S3 as requested in #28) should be a lot easier, as you basically only have to implement an IFileSystem (so Umbraco can store/retrieve media) and an IFileProvider (so the media can be served and retrieved by ImageSharp) that's exposed by the IFileProviderFactory.

[bergmania]

Overall this looks super good, but I think we should just make it depend on Umbraco 10 + .NET6.

I wonder if it make sense to make a composer to you are not forced to manually insert into your startup.cs. What do you think?

Also, Should we make the classes internal or at least sealed, when we do not expect people to extend them? Just to make our life easier in the future?

Can we use TypeForwardedToAttribute for those types now moved into the common assembly, or does it not support namespace changes too?

[AndyButland]

Looks good to me - two tiny typos fixed with suggestions inline.