[Submodule] Issues for submoduling infrastructure

[michael-hawker]

• Move global usings to props files #15 Global Usings files should be replaced with props file versions to minimize needing to include files in each project, more transparent. for instance, this is a problem currently:

https://github.com/CommunityToolkit/Labs-Windows/blob/3ab75baf6a3246cf9a1891488dbcb52189a64c7e/Windows.Toolkit.Common.props#L33-L35

• Find a better home for certain things like this:

https://github.com/CommunityToolkit/Labs-Windows/blob/3ab75baf6a3246cf9a1891488dbcb52189a64c7e/Directory.Build.targets#L21-L26

• In fact do we need the base props/target files since we have our projects include a common file as a starting point, can we just move all these things (or most of them elsewhere?) - At least maybe for props. Like we should probably just have the Directory.Build.props be the common project info like we have in Windows.Toolkit.Common.props.

• Document which things need to exist for the sub modules to work (like RepositoryDirectory definition)

[michael-hawker]

• global using CommunityToolkit.Labs.WinUI; is in the GlobalUsings_WinUI file, but if we don't use that namespace, then it's a compile error.
• TKSMPL0014 is a warning (no sample in doc), but then I don't think it generates the registry? So then compile error... maybe just a case where we have zero samples which shouldn't happen, but we should probably safeguard in case we see a scenario where someone just uses docs in an app shell or something...
• Noticed this YAML error, think has to do with 'TODO:' note maybe?
  
• In addition to common and template folders, need to document need for putting things in components folder as well as the need for the .config/dotnet-tools.json file. (probably just create a template repo?)

[michael-hawker]

• GenerateAllSolution fails if a component doesn't have a src folder:

common\MultiTarget\GenerateAllProjectReferences.ps1:21 char:14
+   $srcPath = Resolve-Path "$($projectPath.FullName)\src";