doc: describe the lane freedom of reduc_widen_[us]sum and WIDEN_SUM_EXPR

The documentation of the reduc_widen_ssum and reduc_widen_usum patterns says
only that operand 1 is added to operand 2, which reads as though each element
of operand 1 has to be accumulated into the element of operand 0 at the same
position.  Nothing says the patterns are only ever used for a reassociable
reduction, so a port cannot tell whether it is allowed to regroup the input
elements, for example by using a pairwise widening add.

vect_recog_widen_sum_pattern only forms WIDEN_SUM_EXPR
through vect_reassociating_reduction_p, which requires the statement to be a
reduction, refuses a statement nested in the inner loop of an outer-loop
vectorization because the order of the computation matters there, and refuses
a type that needs a fold-left reduction.  The comment on the pattern already
describes the idiom as producing N/2 results by summing up pairs of
intermediate results.  The accumulator is only ever consumed by a horizontal
sum in the epilogue, so the distribution of input elements over accumulator
elements is not observable.

Spell that out in md.texi, along with the constraint that comes with it: an
implementation that adds elements together before they reach the element width
of operand 0 has to widen them first so that no intermediate sum can overflow.
Note that the widen_[us]sum names are left free for a lane preserving pattern.

Give WIDEN_SUM_EXPR the same statement in tree.def.  DOT_PROD_EXPR and SAD_EXPR
are formed through vect_reassociating_reduction_p as well and read the same way,
so add a sentence to each pointing at the WIDEN_SUM_EXPR rule.

gcc/ChangeLog:

	* doc/md.texi (reduc_widen_ssum@var{n}@var{m}3)
	(reduc_widen_usum@var{n}@var{m}3): Document that the assignment of
	input elements to accumulator elements is unconstrained, that
	intermediate sums must not overflow, and that the widen_[us]sum
	names are reserved.  Fix a typo.
	* tree.def (WIDEN_SUM_EXPR): Document that the assignment of elements
	of the first argument to elements of the second is unconstrained.
	(DOT_PROD_EXPR, SAD_EXPR): Note the same freedom.

Signed-off-by: Kyrylo Tkachov <ktkachov@nvidia.com>