Consider following situations:

• foo-1-1 has x-1-1 parent image.
• foo-1-2 has y-1-1 parent image.
• bar-1-1 has foo-1-1 parent image.

When Freshmaker generates the list of images to rebuild, the current code
does not handle the case when older foo image was built against x-1-1
and newer foo against y-1-1 well. It will generate following list:

• bar-1-1 will be rebuilt against foo-1-2, because foo-1-2 is the latest release.
• foo-1-2 will be rebuilt against x-1-1, because original parent ofbar-1-1wasfoo-1-1and it depended onx-1-1. This is wrong. In fact, it should be built against
  latest release of y which is y-1-1.

This PR fixes this problem by introducing another initial phase in code which
deduplicates images to rebuild.

In this phase, Freshmaker will search for cases when older image has different
parent than the newer image and if it finds such case, it will replace the
parents completely according to latest image, because we will in the end
use the latest image.

In our example, it will do following in this initial phase:

• It finds out that foo-1-1 has different parent than foo-1-2.
• It knows that foo-1-2 is latest, and therefore it will change the
  foo-1-1 parent of bar-1-1 to foo-1-2, include its dependency
  on y-1-1.

After this initial phase, the bar-1-1 will have foo-1-2 dependency.
This will make Freshmaker to generate proper list of images to rebuild.