Generate IProjectMetadata types even when not referencing projects from the AppHost

Today, the targets in `Aspire.AppHost.Sdk` and `Aspire.Hosting.AppHost` generate implementations of `IProjectMetadata` for each `` in the AppHost project as part of the behavior of treating project references as project resources. These generated types can then be passed as a generic argument to `build.AddProject(...)` to make adding projects as resources simple and type-safe.

With #12829 introducing support for disabling the project reference behavior, we should investigate ways to enable the code generation of these types even when project references aren't present, so that the type-based approach to adding projects as resources can be maintained without the need to reference the projects from the AppHost.

Some thoughts:

- Move the code generation into an actual source generator (today the types are generated from an MSBuild task)
- The targets would be updated to discover "sibling" and "descendent" projects of the AppHost project and store them in a format that can be accessed by the source generator (e.g. new custom item type, generated json file in intermediate output passed as `AdditionalFile`, etc.)
- We'd want to try and limit the discovered projects to those:
- Next to or beneath the AppHost project
- That produce executable outputs (i.e. they're apps). No point generating metadata implementations for class library projects.
- The source generator would then generate the implementation classes based on the passed in discovered projects data

@baronfel interested in your thoughts on implementation here, as we're likely wanting to extract info from a bunch of discovered projects from a task running in the context of another project (hope that makes sense).