Feature: Display test pages in testing app for single experiment head

### Describe the feature

When developing tests, it can be beneficial to see the test page to develop it, just like any other sample.

May also make debugging tests easier if a failure is happening and you want to see what the page looks like for the setup of a test.

The feature would be about adding additional tabs to the TabbedPage interface when running a component in the single-head mode for that component alone (wouldn't be included or do anything when run all-up as the all component mode).

### Desired behavior

When running the single component head, you'd be able to open each test page like you do samples. (Eventually we may need better organization of the tabs here as components get more complex or add many samples/tests.)

When clicking on the tab, it'd just load the test page.

We wouldn't necessarily need to connect the driving test code to this, though it may be required to include the whole test project if more than just code for a page is used for testing, we wouldn't know the full implementation details.

Basically in the `App.Head.props` file we should include the component's test shared project code in this item group:

https://github.com/CommunityToolkit/Tooling-Windows-Submodule/blob/35c03dff2df6a1423860710e6633faf65cf3e788/ProjectHeads/App.Head.props#L46-L58

We'd also need to include the `Log` and `VisualUITestBase` classes that the test code may reference (we can't just include the test shared project as it has the App.xaml test head which would conflict with our app head code).

Ideally, we'd use a source generator again here to detect and index these test pages like we do for samples, then the TabbedPage would just get another bucket of pages and a template in order to show them. (We should probably define a class/record for passing info to the TabbedPage over the tuple we have now.)

### Screenshots

_No response_

### Code Platform

- [X] UWP
- [X] WinAppSDK / WinUI 3
- [ ] Web Assembly (WASM)
- [ ] Android
- [ ] iOS
- [ ] MacOS
- [ ] Linux / GTK

### Windows Build Number

- [ ] Windows 10 1809 (Build 17763)
- [ ] Windows 10 1903 (Build 18362)
- [ ] Windows 10 1909 (Build 18363)
- [ ] Windows 10 2004 (Build 19041)
- [ ] Windows 10 20H2 (Build 19042)
- [ ] Windows 10 21H1 (Build 19043)
- [ ] Windows 11 21H2 (Build 22000)
- [ ] Other (specify)

### Other Windows Build number

_No response_

### App minimum and target SDK version

- [ ] Windows 10, version 1809 (Build 17763)
- [ ] Windows 10, version 1903 (Build 18362)
- [ ] Windows 10, version 1909 (Build 18363)
- [ ] Windows 10, version 2004 (Build 19041)
- [ ] Other (specify)

### Other SDK version

_No response_

### Visual Studio Version

_No response_

### Visual Studio Build Number

_No response_

### Device form factor

_No response_

### Additional context

In the future, we could investigate a way to trigger running a test method against the page that it has been linked to in order to facilitate reproducing tests while being able to watch them or better interact with visual tree tools, etc... (this would probably require more information from a source generator to generate a look-up that's easier/faster to reference)

### Help us help you

Yes, but only if others can assist.

Inizia leggendo il gruppo di elementi App.Head.props collegato nell’issue, quindi segui l’indicizzazione degli esempi esistente e l’implementazione di TabbedPage. Verifica come vengono incluse le classi Log e VisualUITestBase e come il source generator espone le pagine di esempio. Il lavoro è completato quando le pagine di test appaiono come schede in single-component head mode, vengono caricate quando selezionate e non hanno alcun effetto in all-up mode.

Scritto dal modello di indicizzazione a partire dal testo della issue.