Don't drop the tasklet lock inside the handler

Formerly, tasklet handlers were called with the tasklet's lock held,
and were expected to release it.  This wasn't ideal, because it is
generally better if the place that acquires a lock is also responsible
for releasing it.  But the rationale was that sometimes a tasklet handler
wants to destroy the tasklet and the associated lock; thus run_queue_run
cannot simply unlock after calling the handler.

Hbut that rationale only applied when tasklet_fini was called.  And
the case where a handler calls tasklet_fini on its own tasklet is already
detected and special-cased in a few ways.

Hence a new convention: The tasklet handler's caller will acquire and
release the tasklet lock, except in the case where it calls tasklet_fini.
In that case it must release its own lock (usually be calling
mutex_unlock_fini; there was only one place in the existing codebase
where a tasklet_fini was not followed by the destruction of the
associated lock, thus requiring an explicit mutex_unlock).

As well as the impact on locking within tasklet handlers, this change also
means that when tasklet_goto is called to start a tasklet, the associated
lock should be held and afterwards released.  But again, this makes
locking correctness easier to verify.