After setting file priority, any subsequent attempt to set different priorities will fail if there is a `file_priority` job running in in disk thread. This happens because `torrent::m_file_priority` is being updated before adding disk thread job. The problem is gone if the file priority vector owned by the torrent object, is modified in the `torrent::on_file_priority` callback, when disk job finishes.
1. Replace custom 'shared' option with the standard BUILD_SHARED_LIBS
flag
2. Replace foreach() calls for source items with target_sources() and
generator expression $<JOIN:>.
3. Remove build types definition: makes no sense for
single-configuration generators, and is populated automatically for
multi-configuration ones.
4. Add feature summary
5. Enahnce compiler flags management for static runtime by utilizing functions
from the ucm project
6. Copy almost all options from the Jamfile.
7. If compiler supports C++14, use it.
8. Raise minimum required CMake version to 3.11 and drop bundled FindIconv.cmake
Most status alerts should have priorities above normal level. Good reason for this is resume data verification case. For a large torrent(having lots of pieces) whole alert queue will be overflowed
with a `piece_finished_alert` right after resume data has been verified. Thus alerts like `torrent_checked_alert`, `torrent_finished`, `state_changed_alert` will not go the alerts queue.
* Introduce alert_priority enumeration
* Bump state_changed_alert's priority
* Set dht_direct_response_alert priority to `critical`
If `default_storage::has_any_file` fails during fastresume data check, `piece_manager::check_no_fastresume` will skip storage initialization. In such case, any storage operation that require part file will cause an application crash.