[New Feature]: Split Dotnet packages by architecture

Nobody has claimed this yet.

### Description of the new feature/enhancement

Hi,

I was wondering if we could split packages per architecture:
- Microsoft.DotNet.DesktopRuntime.8
- Microsoft.DotNet.DesktopRuntime.10
- Microsoft.DotNet.Runtime.8
- Microsoft.DotNet.Runtime.10
- and other "DotNets"

Basically do similar to what has been done to VCRedist, e.g.
- Microsoft.VCRedist.2015+.arm64
- Microsoft.VCRedist.2015+.x86
- Microsoft.VCRedist.2015+.x64

Many Microsoft.DotNet* packages have issues with side-installation of packages with different architecture:
- sometimes updates of singular packages don't work correctly
- can't uninstall singular package without uninstalling second one with --all-versions
- sometimes installation is also not possible

Additionally it's not possible to install any Dotnet with x86 using DSC as there is option for that. Splitting packages would resolve this issue as architecture would be defined in the name itself.

For all those issues there were reported numerous similar issues, to this repo and winget-cli
- [#5731](https://github.com/microsoft/winget-cli/issues/5731)
- [#5729](https://github.com/microsoft/winget-cli/issues/5729)
- [#4883](https://github.com/microsoft/winget-cli/issues/4883)
- [#3010](https://github.com/microsoft/winget-cli/issues/3010)
- [#5722](https://github.com/microsoft/winget-cli/issues/5722)
- [#5721](https://github.com/microsoft/winget-cli/issues/5721)
- #117876
- #183481

I believe that the best option would be to implement reliably identify architecture, and [add architecture options for winget-cli](https://github.com/microsoft/winget-cli/issues/3401). But issues against that were reported 3 years ago and where still not resolved.
Maybe in the meantime we could just create copy of those packages with architecture in the name?
We could still leave old ones and give them updates, but make copy and recommend people to use new ones.

If there is help needed with this implementation I can do that

### Proposed technical implementation details (optional)

_No response_

The issue names no files, tests, or entry points. Start by reviewing the linked winget-cli issues and the existing VCRedist architecture-specific package examples; done would require an agreed, reliable approach for separate DotNet architecture packages and their installation, update, and removal behavior.

Written by the indexing model from the issue text.