BlazorWebView support for loading custom static assets

[Eilon]

Each platform's BlazorWebView has a new virtual CreateFileProvider() method that you can override to return a custom IFileProvider to return static assets from wherever you want (such as embedded resources, generated, etc.).

Fixes #1520

The .NET MAUI/WinForms/WPF BlazorWebViews can now all load static assets from a custom IFileProvider.

Each platform's BlazorWebView control has a new virtual method:

	/// <summary>
	/// Creates a file provider for static assets used in the <see cref="BlazorWebView"/>. Override
	/// this method to return a custom <see cref="IFileProvider"/> to serve assets such as <c>wwwroot/index.html</c>.
	/// </summary>
	/// <param name="contentRootDir">The base directory to use for all requested assets, such as <c>wwwroot</c>.</param>
	/// <returns>Returns a <see cref="IFileProvider"/> for static assets, or <c>null</c> if there is no custom provider.</returns>
	public virtual IFileProvider CreateFileProvider(string contentRootDir)
	{
		return null;
	}

To serve custom static assets, create a derived BlazorWebView that overrides the new CreateFileProvider method to return custom assets:

	public class CustomFilesBlazorWebView : BlazorWebView
	{
		public override IFileProvider CreateFileProvider(string contentRootDir)
		{
			return new CustomFileProvider(...);
		}
	}

This PR includes samples for each platform that shows how to serve static files from an "in-memory" storage.

[Eilon]

It might look like it's kind of a large PR, but it's like 80-90% sample updates, and only a small amount of product code changes.

[Eilon]

BTW I did consider and dismiss some other design options that I figured I'd mention here in case anyone has other thoughts:

1. Expose this functionality as an event instead of a virtual override. This would involve introducing a custom event args type to provide a place to get the contentRootDir and set the IFileProvider that would need to be duplicated (or even triplicated) because WPF/WinForms/MAUI don't all share a common reference.
2. Expose this via DI. Similar to (1), we'd need to duplicate/triplicate some new service type, e.g. IBlazorWebViewFileProvider, because we need a method with a signature that takes in the contentRootDir.
3. Expose this functionality as a property. This wouldn't work on its own because there needs to be a place to provide the contentRootDir, which you can't really do in a property.

I felt that all of these would be unnecessarily icky compared to the scope of this feature.

[mattleibow]

Looks pretty good, but I suppose I think I would prefer to use a FileProvider property over a method override.

[mattleibow]

Should this maybe be a property? I feel setting webview.FileProvider = Xxx is easier than overriding. Unless I am missing some reason why this is better? Maybe even a bindable property so it can be swapped out? Unless swapping is not possible, but then I could swap out via the override logic, so that needs to be supported either way.

[mattleibow]

And, if it is a property, then the handler can have a mapper that can update the native things.

[mattleibow]

Looking at the samples with the overrides... I feel that this is not very XAML-y - an override just to return a single value...

[mattleibow]

And I see your last point on the last comment is not this... Hmmm.

[Eilon]

I'd love a property if I had a way of passing in a parameter to it... which would mean I need a new interface with such a method on it... which would mean I'd need 3 because of WPF/WinForms/MAUI.

[mattleibow]

Seems the FileProvider is not as simple as I thought, so we can't quite use a property as it is made up of values and that is passed to it.