fix: exclude arrays of built-in types from CouplingBetweenObjects

[jonbaldie]

Summary

CouplingBetweenObjects normalized scalar built-in type names but left the trailing array rank attached, so int[] failed the built-in comparison and added a false dependency. Twelve user-defined field types plus one primitive array reported coupling 13 and triggered the rule; removing int[] alone dropped it below the threshold (#87).

BaseTypeName now strips trailing array rank and pointer syntax (int[], int[,], int[][], int*) before the built-in comparison, then the nullable suffix (int?[], int*[]?). Existing leading-syntax trimming, generic stripping, and qualified-name handling are unchanged. Arrays of user-defined types still count one dependency for their element type, in every path the rule reads a type (fields, parameters, return types, object creations).

Testing

• Regression tests cover primitive arrays across field, parameter, and return positions (CouplingBetweenObjects_PrimitiveArrayNotCounted, CouplingBetweenObjects_PrimitiveArrayParameterNotCounted) — both watched red before the fix.
• CouplingBetweenObjects_UserDefinedArrayStillCounted asserts an array of a user-defined type counts exactly once via its element type (coupling 12, not 13 or 11).
• CLI end-to-end on the issue's fixture: twelve user-defined fields plus int[] now exits 0; the same fixture with M[] still reports coupling 13 and exits 2.
• Full suite: 458 passed; dotnet format --verify-no-changes, Release build with warnings-as-errors, and self-analysis (csharp,codesize,design) all clean.

Fixes #87

🤖 Generated with Claude Code