Close torrent file descriptors on the disk thread.

[j-c-m]

This change keeps file closing from blocking main (ui / peers network activity). I have another PR to open which moves munmap and sync to the disk thread as well, these both help transfer rates and ui feel as they no longer block on the main thread.

Detach FileManager bookkeeping on main, then queue raw fds for ::close on rtorrent disk so least-active and close_all_files do not block the peer/UI thread on slow FS teardown.

[rakshasa]

Disk thread does hashing, so we don't want time-sensitive actions like freeing up fd's to be done there.

Seems this would be better as a separate class in torrent/system that you can pass fd's to close, it uses std::async and atomic signals, and if we're starving for fds you can call a function to block until fd closes have completed.

[j-c-m]

I'll look at it (wondering if is better to just have another worker thread to handle close/munmap/msync vs std::async, was trying to avoid adding excess complexity). With #834 I went from running against almost whatever limit there was, to basically only a handful of open and active fds, which makes the dance around the file limit rare and allows libtorrent to tolerate time to close. (this PR does have close_fd_now() which blocks at the limit)

[rakshasa]

Check j-c-m-feature/disk-thread-close (not tested)