install_initd tests: new issues

Running the latest version of the tests on Debian
turned up two failures that on reflection I think
are a hole in the test strategy, not an implementation
bug.  I made some changes to the reporting to help
track this down more easily, thus the recent checkins.

I may still be interpreting this wrong, perhaps there
are real bugs that can also be explained away by
this logic. However...

The two fails are in general.sh:

- tp3 install_initd A without previously install_initd B
suceeds (which is a FAIL)

- tp4 remove_initd B after install_initd B fails
(which is a FAIL)

I believe the reason is that Debian computes dependencies
with the aid of a cache in /var/lib/lsb, so it doesn't
have to recompute the information every time.

Because tp2 runs before tp3 in the normal case, and
because tp2 activated both initscripts, this system
thinks they're activated.  the test "cleanup" code is
just to remove the symlinks, but not actually calling
remove_initd means the system is going to think they're
still active.  thus tp3 is going to think the required
dependency is met.

There's nothing in the spec to say this is not a valid
implementation - it clearly is.

I think the testsuite cleanup routine is going to have 
to call remove_initd, perhaps in addition to manually
wiping out the files.

For the second situation the fail is explainable the
same way:  from tp3, A is still considered installed
(the install succeeded unexpectedly (to the test)),
thus removing B can't work because A depends on it
and is still installed.