fix: possible heap-use-after-free with magnet links

[tearfur]

Fixes #6706.
Stack trace at #4178 (comment).

This PR backtracks some changes made in #6383:

• Reverted a change that queues the tr_torrentVerify() call instead of executing it immediately after completing the metadata of a magnet link. This is the crux of the bug this PR fixes, more on that below.
• Re-implemented tr_torrentMagnetDoIdleWork() that got removed.

#6383 changed tr_torrent::on_metainfo_completed() so that it queues tr_torrentVerify() to be executed in the session thread when it is free, instead of executing it immediately.

This was needed because tr_torrentVerify() will stop the torrent, thus freeing all tr_peerMsgs objects belonging to that torrent (i.e. disconnecting all peers), and this might trigger a chain reaction (detailed at #6383 (comment)) that leads to heap-use-after-free.

However, an unexpected consequence of this change is, there is a chance that tr_torrentVerify() will be executed after the original tr_torrent object for the magnet link is destructed, causing heap-use-after-free. This can happen if the magnet link got removed from Transmission or the session itself got shut down immediately after the metadata transfer completed.

A side effect of this PR is that we need to re-introduce the indirection step tr_torrentMagnetDoIdleWork(), otherwise there will be heap-use-after-free. I made the changes in #6383 because I didn't like how it worked, but for now I don't see any better solution other then reverting to the way it was.

[Coeur]

Looks good. Thanks

[ckerr]

I like this change!

IMO we can do this without exposing a new public method in tr_torrent but 👍 with the approach of moving this to an idle func