Fix: libpacemaker: Honor role-based colocations for bundles

Previously, colocations involving promotable bundles did not work
reliably. They did not work at all if the bundle was the dependent.

The fix is multifaceted. First, the bundled resource and its instances
now receive the bundle's colocations after promotable role selection
has begun. (This was done in the previous commit.) They don't need the
bundle's colocations during assignment -- only the bundle's replicas'
containers are relevant at that point. However, a container can never be
promoted, so we need to be able to check the role of the bundled
resource running inside it, in order to determine the replica's "role".

We update pcmkcolocation_affects() and pcmkapply_coloc_to_priority()
accordingly. If a resource is a bundle replica container, we get the
role of the bundled resource instance running inside it, if any.

Part of applying colocations to the dependent when the bundle is primary
is choosing a compatible instance of the primary bundle. For
promoted-bundle-with-promoted-bundle colocations, the dependent may be
an instance of the bundled resource. If so, the dependent's location
will be a bundle node. We need to compare the bundle node's host, rather
than the bundle node itself, against the primary container's location.

This fixes the cancel-behind-moving-remote test that was temporarily
broken in the "Don't shuffle clone instances unnecessarily" commit.

There may be some opportunities to reuse some of the code from
pcmkclone_assign() and/or pcmkclone_apply_coloc_score() for the
bundled clone. For a promotable bundle, after all, the bundled resource
is a promotable clone. However, thus far it seems that the bundled
resource assignment and roles are too tightly interwoven with the
assignment of the bundle replica containers. Straightforward approaches
to reuse clone code were unsuccessful. It seems that it would be too
complicated unless we begin a larger overhaul of bundle code in
libpacemaker.

I was particularly surprised that this didn't involve updating
pcmkupdate_dependent_with_promotable() or
pcmkupdate_promotable_dependent_priority() directly, or adding any new
calls to them... those might play a role in any future refactors.

Fixes T672
Ref T489

Signed-off-by: Reid Wahl <nrwahl@protonmail.com>