Refactor remaining Project and Build files

[Nirmal4G]

Info

Extracted from CommunityToolkit/WindowsCommunityToolkit#4234 as the Common Code projects were separated in this new repository.

Changes

Simplify Roslyn multi-targeting

• Refactor Roslyn multi-targeting to use multiple projects
  in the same project directory without using Shared projects.
• This refactoring is made in preparation for the solution to use
  the NuGet's CPVM and TargetFramework as alias features.
• This also slightly improves IDE load time and Build performance.

Move MSBuild logic into new files

• Move the T4 MSBuild logic to a new file.
• Move Public Key to a new file toolkit.spk.
• Move MSBuild logic to near-by Directory.Build.{props|targets} files.

Simplify MSBuild logic in project files

• Add necessary guard to check for pack.
• Remove redundant properties and values.
• Remove and adjust quotes in property functions.
• Use wildcards to generalize and reduce items declared.

Add, Update and Format build Comments

• Remove redundant comments.
• Add missing comments on certain code blocks.
• Format code in comments with proper quote style.

Misc Changes

• Fix the text flow warping in the MSBuild Console logging.
• Use checked version properties instead of hard-coded checks.
• Update the structure of the projects list in the Solution file.

PR Checklist

• Created a feature branch in your fork
• Based off latest main branch of toolkit
• PR doesn't include merge commits (always rebase on top of our main)
• Header has been added to all new source files (ran build/Update-Headers.ps1)
• Tested code with current supported SDKs
• Contains NO breaking changes
• Code follows all style conventions

Notes

Please suggest alternate names for dotnet Community Toolkit.sln. We have already established that we can't use .NET.
I tried using NET, DotNET, dotNET and Core as prefix. Except for Core, others neither look good nor stand-out in the file list.

• Rebase merge please.
• When merging, please update the commit title to PR title instead of the default Merge pull request #xxxx from repo/branch, and commit message to either PR message or messages of individual commits. The auto-merge option does this by default.

[Nirmal4G]

Project File structuring

• SOF (Start Of File) Imports,
• Core properties, Package properties, build properties,
• Build items, Resource items, Content items, Misc. items,
• In-place Imports, Choose (elements within follows outer sort order)
• ProjectReference items, PackageReference items,
• Targets and Properties and Items close to said Targets,
• EOF (End Of File) Imports.

Where there's a condition by target properties, we should group them together under Choose. For multiple target values, we should sort them by the order in which they are defined. And the order in which they should be defined is either ascending or descending in terms of compatibility layering.

[Nirmal4G]

@Sergio0694 PR closed by 237 by mistake. Can you reopen it?

[Sergio0694]

Huh, weird, yeah no problem! 😄

[Sergio0694]

Left some nits 🙂

[Nirmal4G]

@Sergio0694 Updated in response to PR #428 which broke this!

[Sergio0694]

Just a heads up, there's major changes I'm doing in #436, so this PR will need updates after that as well.

[michael-hawker]

Still going to suggest that we close this PR, as it should be broken out into smaller PRs as mentioned above.

@Nirmal4G in general doing things like renaming a directory from build to eng has little purpose or value to the project and just creates noise in these PRs. It's something that should be discussed in an issue first, folks can agree on a timing and value of the proposal, and then it can be coordinated with others working on the repo for a major folder restructure between releases.

Similarly, unless we can automate structuring of the project file XML with a tool like XAML Styler does for XAML files in the WCT repo, then manually moving Item/PropertyGroups around is just a temporary thing that also just creates more noise that's hard to review. Especially when mixed in with other changes in part of a larger PR.

Diving into making changes can be fun and exciting, but if you want to ensure your contributions are having a meaningful impact and will be merged; it's best to start a conversation with an issue or discussion first to lay out exactly what you plan to do, how it benefits the project, and what's involved with the change. This should be scoped to something that's a single 'block' and not a laundry list of lots of items. Each idea should be its own issue.

Or ask to pick up an already open bug or issue on the repo that someone's not working on or reach out on Discord to Sergio or myself and ask if there's something on the top-of-our-minds build related that we're struggling with that you could assist with. Really happy to have your passion directed at our projects, but we just want to ensure we're on the same page and can move forward together! Thanks!

[Nirmal4G]

@michael-hawker This is still in draft! Also this is on top of existing PRs. Changes that are mutually exclusive are separated but when they are cumulative, how they can be separated?

Code changes are one thing but refactorings are if not always cumulative and to produce clean diff and blame, they need to be arranged properly by theme of change or purpose of change.

I'm still a novice but if may ask, how would you separate this patch without causing conflicts that break build!?

[Nirmal4G]

@michael-hawker There's a discussion open for these PRs. It's part of a larger refactoring with the goal of introducing a common build infra for Community Toolkit repos (or atleast for my forks if we're not moving forward with the idea!).

1. [Build] Centrally manage NuGet package versions WindowsCommunityToolkit#4691
2. Improve build infra for .NET Community Toolkit repository #463

[wzxprince]

I am Chinese！！！I like it！