force-autopkgtest semantics

[Scott Kitterman]

Currently if you need to force a package past an autopkgtest you need to do 
the force-autopkgtest on the package which triggered the test, not the one 
that's attempting to migrate.  As an example, today we were trying to get kde-
baseapps to migrate quickly so that we could get our Alpha 1 images built, but 
it triggered an autopkgtest in pango1.0.  This could be obviated with a force:

force-autopkgtest pango1.0/1.32.5-5ubuntu1

This is suboptimal for multiple reasons:

1.  If an attempted migration triggers more than one test, you just end up 
blocked on the next test and then have to force that one too (that happened in 
this case).  Autopkgtesting delayed migration at least three publisher cycles 
today when we really were trying to drive things to closure for the milestone.

2.  If, for some reason more than one package is depending on that test run, 
they all get forced, not just the package that's needed.

The current approach makes sense for the case of a known broken autopkgtest.  
If that's the case, we can put the force-autopkgtest in and leave it until the 
test is fixed without interfering with other migrations.  It's not so great, 
however, for the case we hit today where we are trying to speed migrations 
along.

Would it be possible to support force-autopkgtest on either the package under 
test or the triggering package.  Then, for today's case, we could have done:

force-autopkgtest kde-baseapps/4:4.10.80-0ubuntu1

That would then skip all autopkgtests that might be triggered by the 
transition.

I understand why we have the approach we have now, but there are other cases 
as well where being able to do it the other way around would be helpful.

Scott K