Add a direct way to get asynchronous results

[glassez]

(It's something a bit like #7558. But unlike it, it should not depend on alerts.)

Now, to get some data from libtorrent, we have two options - either use a blocking call or receive the result asynchronously through alerts.
The first way is bad for interactive applications, because it either blocks the main thread, which can cause GUI to hang, or we have to workaround this by using some tricks with additional threads (as if making it asynchronous).
The second way is also inconvenient, as it makes the code confusing and requires additional tricks. IMO, alerts are good for use within the Observer pattern (for example, when tracking some internal events or when it makes sense to have a request and receive data in different piece of logic), but they look unsuitable when requesting data directly.
Earlier, I suggested simply implementing direct access to such data from app thread with mutex-based protection, but this was rejected due to the reluctance to mess with mutexes in libtorrent in order to ensure correct multithreaded access. I agree, it could look more complicated than the current event-based access way.
But nevertheless, I would highly like to get a friendlier way of getting the data.
Now I believe that futures could be a good option in this matter. Leaving libtorrent to its current method of implementing data access through an event queue, futures could provide the user side with a direct way to obtain the results of these access requests, deciding on its own whether to do it synchronously or asynchronously.
So all methods like torrent_handle::get_peer_info(), torrent_handle::url_seeds(), session_handle::is_listening(), session_handle::listen_port(), torrent_handle::piece_availability(), torrent_handle::get_download_queue(), torrent_handle::trackers(), torrent_handle::status() (and maybe some other similar ones not mentioned here) should return std::future instantiation with appropriate result. (This will also make previously added post_* methods and their corresponding alerts unnecessary.)
Some other methods that would make sense to use in different patterns (e.g. torrent_handle::save_resume_data()) could have both a return value of type std::future and a corresponding alert.