Fix scaffolding failure when DbContext/model classes live in a separate referenced project

[Copilot]

Scaffolding CRUD controllers, Razor Pages, Blazor, etc. fails with Invalid --model / Invalid --dataContext when the DbContext and model classes are defined in a separate class library referenced via ProjectReference, instead of in the project passed to --project.

Root cause

• CodeService.GetAllClassSymbolsAsync() only inspected syntax trees from the main project's own compilation, so any class declared in a referenced project (e.g. a shared data/models library) was invisible to the model/DbContext lookup used by all Validate*Step scaffolding steps.

Fix

• GetAllClassSymbolsAsync now walks the Roslyn project dependency graph (GetProjectsThatThisProjectTransitivelyDependsOn) to find every project transitively referenced by the main project.
• Compilations for each referenced project are fetched and their class symbols merged with the main project's, de-duplicated via Distinct.
• Entry-point resolution (GetEntryPoint) remains scoped to the main project's compilation only, since referenced class libraries have no entry point.

// Before: only classes in the main --project compilation were visible
// After: classes in transitively-referenced projects (e.g. a Data/Models class library)
// are also discoverable for --model and --dataContext resolution
var allClasses = await projectInfo.CodeService.GetAllClassSymbolsAsync();

• Fixes Scaffolding doesn't work when DbContext is in a separate project #3771