Fix Warray-bounds warning for fixed-size assignments

Reference issue

#2506 (closed) Fixes #2900 (closed)

What does this implement/fix?

Currently, we only consider the left-hand side / destination of an assignment expression for the purpose of evaluating the traversal and unrolling heuristics. As pointed out by the OP of #2900 (closed), we sometimes attempt a vectorized traversal even when the size at compile time is smaller than the size of one packet, which generates code that is never executed and probably some compiler warnings. Whenever possible, we should consider the compile-time information provided by all arguments in an expression.

Examples:

VectorXf lhs, Vector2f rhs;
lhs.head(2) = rhs;

Currently, Eigen will consider the left-hand side, which is completely dynamic and attempt a LinearVectorizedTraversal with a Packet4f, even if its not possible. With this MR, Eigen only attempts a LinearTraversal with CompleteUnrolling. This is accomplished by considering the MaxSizeAtCompileTime of the entire expression (2), which is less than the size of Packet4f (4).

Matrix<float, 7, Dynamic> lhs(7,7);
Matrix<float, Dynamic, 7> rhs(7,7);
lhs = rhs;

Currently, Eigen will consider the left-hand side which has a dynamic SizeAtCompileTime and attempt a LinearVectorizedTraversal with NoUnrolling. With this MR, Eigen pieces together that the expression is a 7x7 assignment at compile time and chooses CompleteUnrolling. This is accomplished by deducing that there are 7 rows (7, Dynamic) and 7 cols (Dynamic, 7). Instead of querying the SizeAtCompileTime of both the left-hand and right-hand sides, the rows and cols are multiplied, which is more information than either side could provide by itself.

Similar opportunities in other compound expressions, like https://gitlab.com/libeigen/eigen/-/blob/master/Eigen/src/Core/CwiseBinaryOp.h#L27

Additional information

Big CI https://gitlab.com/libeigen/eigen_ci_cross_testing/-/pipelines/1664785886