Fix: scheduler: attenuate chained "with this" colocation scores

When assigning a primitive (via pcmk__primitive_assign()), the preferences
of resources colocated with the primitive are incorporated by calling the
dependent's add_colocated_node_scores() method (via apply_with_this()).

The dependent's node preferences are added to the primary's, attenuated by a
factor equal to the colocation score divided by INFINITY. Thus, for a mandatory
colocation, the dependent's preferences are incorporated at full strength,
while for an optional colocation, they are incorporated at a percentage (for
example, 10% for a colocation with a score of 100,000, or 1% for a colocation
with a score of 1,000).

The process is recursive so that the preferences of resources colocated with
the dependent are also considered, and so on.

Previously, those chained preferences were incorporated at a factor based on
their own constraint's score. So, a chained mandatory colocation would get its
dependent's preferences incorporated at full strength, which is clearly not the
intention and less than ideal. (For example, given "C with B @ INFINITY" and
"B with A @1000", A would consider B's preferences at 1%, but C's preferences
at 100%.)

It is not obvious how non-infinite scores should be attenuated for such
consideration, and the choice seems somewhat arbitrary. But to choose something
reasonable, chained colocations are now incorporated at their own factor times
the original factor, to reduce their influence. (With the above example, B's
preferences would be considered at 1%, and then C's would also be at
INFINITY / INFINITY * 1% = 1%. This does mean that multiple chained optional
colocations will quickly have their influence reduced to a negligible amount,
but that seems reasonable for placement of the original primary.)

Fixes T215