Fix inconsistent typeSize calculation for TupleN vs recursive pair encodings

[Lluc24]

Currently, typeSize reports inconsistent values for standard tuple types (e.g., (A, B)) compared to their semantically equivalent recursive pair encodings (e.g., A *: B *: EmptyTuple).

This discrepancy arises because TupleN is represented as a flat AppliedType, whereas the nested encoding forms a deeper tree structure. As typeSize is often used as a heuristic for complexity or optimization limits, this inconsistency can lead to divergent behavior in the compiler depending on how a tuple is represented syntactically.

This PR modifies TypeSizeAccumulator to canonicalize TupleN types into their recursive *: representation before calculating their size. This ensures that the size metric is consistent regardless of whether the tuple is represented as a flat AppliedType or a nested structural type.

I have added a new unit test in TypesTest that asserts Tuple3[Int, Boolean, Double] and Int *: Boolean *: Double *: EmptyTuple both yield identical typeSize equal to 3.

Thanks to @mbovel for providing the unit test that effectively reproduces this issue and validates the fix.

Fixes#24730

[mbovel]

We could maybe use normalizedTupleType here:

scala3/compiler/src/dotty/tools/dotc/core/TypeUtils.scala

Lines 148 to 157 in f67a1a0

	/** If this is a generic tuple type with arity <= MaxTupleArity, return the
	* corresponding TupleN type, otherwise return this.
	*/
	defnormalizedTupleType(usingContext):Type=
	if self.isGenericTuple then
	self.tupleElementTypes match
	caseSome(elems) if elems.size <=Definitions.MaxTupleArity=> defn.tupleType(elems)
	case _ => self
	else
	self

[mbovel]

Suggested change

	valtpNorm= tp.tryNormalize
	if tpNorm.existsthen apply(n, tpNorm)
	valtpNorm= tp.normalized.normalizedTupleType
	if tpNorm ne tpthen apply(n, tpNorm)