Import: Don't walk non-F# assemblies when labelling trait constraint sources

[auduchinok]

Prevents eager reading of all types in referenced non-F# assemblies, saving memory on projects with many references.

AI-generated summary:

addConstraintSources (added in #16304, so that a failed member constraint names the member it came from) is applied to every imported assembly, and recurses through e.ModuleOrNamespaceType for every module and namespace entity it finds.

For an assembly imported from IL there is nothing to find: the walk only reads AllValsAndMembers, and ImportILTypeDefs gives every namespace and type entity an empty val list; only an F# trait constraint produces a TyparConstraint.MayResolveMember to label in the first place. Meanwhile the recursion forces each namespace entity's ModuleOrNamespaceType, which imports that namespace - so referencing an assembly ends up importing every namespace in it, and reading every type definition, whether or not the code touches it.

Skip the CCUs that aren't F#. FSharp.Core and F# references are still walked, so the error messages are unchanged.

Measured with FSharpChecker.ParseAndCheckProject, keeping the results alive so the imported assembly structures stay on the heap (averages of 3 runs, one per process): a 486-reference F# project retains 1319.2 -> 952.1 MB (-27.8%), and a 168-reference console project 77.7 -> 69.8 MB (-10.2%). Checking FSharp.Compiler.Service itself (124 references, 397 sources) goes 2301.7 -> 2298.0 MB, i.e. within the noise at that size - what the imports cost there is dwarfed by the trees of the project's own code.

[T-Gro]

🤖 AI review (@expert-reviewer): no significant issues found. Please verify independently.

Reviewed the change to addConstraintSources in CompilerImports.fs. The fix is correct and well-scoped:

• The guard ia.FSharpViewOfMetadata.IsFSharp is cheap — IsFSharp is a plain bool field on CcuData (TypedTree.fs:5854), so reading it does not force Deref to materialize the namespace tree, which is the whole point of the optimization.
• The inner addConstraintSources is a non-recursive let that shadows and wraps the outer function; addConstraintSources ia in its body correctly refers to the outer definition. This is subtle but works as intended.
• The guard is semantically sound: only F# assemblies produce TyparConstraint.MayResolveMember constraints to label, so skipping IL-only assemblies cannot change diagnostic output. FSharp.Core and F# references (IsFSharp = true) are still walked, so error messages are unchanged.

No correctness, security, or error-handling concerns.