Improve consistency with resizetizer

[mattleibow]

WINDOWS BREAKING CHANGE (see below)

Description of Change

Currently, certain parts of resizetizer are inconsistent across platforms, mainly Windows:

• Windows injects an "Assets" folder in the app package for all resource types
• Windows does not respect the LogicalName attribute on MauiAssets
• Accessing the assets via Essentials's FileSystem.OpenAppPackageFileAsync still required a #if WINDOWS

This PR attempts to fix #3270

WINDOWS BREAKING CHANGE
This change does have a breaking change for Windows where all assets are now no longer in the "Assets" folder. This may require XAML, C# and/or logic changes. However, in most cases, this is more to remove special code than to write new code.

After this PR, you will be able to do this:

Assume there is a asset added:

.csproj	On Disk	In App
<MauiAsset Include="MyAsset.txt" />	/MyAsset.txt	/MyAsset.txt
<MauiAsset Include="MyAsset.txt" LogicalName="YourAsset.md" />	/MyAsset.txt	/YourAsset.md
<MauiAsset Include="Resources\MyAsset.txt" LogicalName="YourAsset.md" /> *	/MyAsset.txt	/YourAsset.md
<MauiAsset Include="Assets\**" LogicalName="%(RecursiveDir)%(Filename)%(Extension)" /> **	/Assets/*	/*

Notes:

* Without the LogicalName, this will fail to build on iOS because the "Resources" root folder is illegal
** Wildcards can be used to move an entire subfolder to the root of the app package

Since all the files go into predictable locations for all platforms, Essentials can be used to read files:

async Task LoadMauiAsset()
{
	using var stream = await FileSystem.OpenAppPackageFileAsync("AboutAssets.txt");
	using var reader = new StreamReader(stream);

	var contents = reader.ReadToEnd();
}

Additions made

• Assets processed by resizetizer (images, icons, fonts and raw assets) are no longer forced into an "Assets" sub folder in the Windows app package
• The LogicalName can optionally be used to control where in the app the asset will go
  One reason for this is that often the folder name of "Resources" is used to contain resources, but this may not be desirable in the app package for a few reasons:
  1. iOS/Mac Catalyst forbids the usage of "Resources" as a root folder name in the app packages
  2. Adding a prefix of "Resources/" to every request for a resource from the resource location is very verbose

PR Checklist

• Targets the correct branch
• Tests are passing (or failures are unrelated)
• Targets a single property for a single control (or intertwined few properties)
• Adds the property to the appropriate interface
• Avoids any changes not essential to the handler property
• Adds the mapping to the PropertyMapper in the handler
• Adds the mapping method to the WinUI, Android, iOS, and Standard aspects of the handler
• Implements the actual property updates (usually in extension methods in the Platform section of Core)
• Tags ported renderer methods with [PortHandler]
• Adds an example of the property to the sample project (MainPage)
• Adds the property to the stub class
• Implements basic property tests in DeviceTests

Does this PR touch anything that might affect accessibility?

• Does this PR introduce a new control? (If yes, add an example using SemanticProperties to the SemanticsPage)
• APIs that modify focusability?
• APIs that modify any text property on a control?
• Does this PR modify view nesting or view arrangement in anyway?
• Is there the smallest possibility that your PR will change accessibility?
• I'm not sure, please help me

If any of the above checkboxes apply to your PR, then the PR will need to provide testing to demonstrate that accessibility still works.

[mattleibow]

No more "Assets" prefix

[mattleibow]

Windows uses Link and iOS/Android uses LogicalName to determine the final destination.

[mattleibow]

The windows:Application.ImageDirectory="Assets" is no longer needed by default.

[mattleibow]

Example asset added to the template.

[mobycorp]

All, while editing the manifest file may be the correct thing to do, something with the template for preview 13 is incorrect. I went back and looked at a preview 12 project and it was exactly the same, but preview 12 worked...