a possible deadlock.

My previous commits stopped a double delete of a tape request by modifying
castor::vdqm::handler::TapeRequestHandler::deleteTapeRequest so that it took
a lock on the corresponding tape request.  Simply taking this lock introduces
the risk of a deadlock.  The tape request may be associated with a drive, and
if so a lock will be required on both the request and the drive.  Care must be
taken as locks are to be taken first on a drive and then on its associated tape
request, otherwise a deadlock may occur.

My modification has been to first get the tape request from its id without
taking a lock on its row, but taking one on the associated tape drive if there
is one.  Once I have a lock on the tape drive, I try to take a lock on the
tape request.