Buffer output in each line

fix wrong miner algorithm in result data

fix #1708

The extension of the job result contains the wrong algorithm used to create the nonce.
The fix provide now the correct used algorithm even if the coin is forking to a new algorithm.

- forward the used algorithm from the miner

remove cryptonight coins

- remove all cryptonight coins (algorithm cryptonight can still be used)
- update README.md

add ryo currency

optimize cn-heavy AMD

- add ryo currency
- update documentation

- explicit loop unrolling

based on changes in @imperdin fork https://github.com/imperdin/xmr-stak/blob/master/xmrstak/backend/amd/amd_gpu/opencl/cryptonight.cl

Fixed fork version for currency 'electroneum'

increase version to 2.4.5

Add support for CryptoNight Haven (small Heavy tweak)

- update pools.txt
- add new algorithm `cryptonight_haven`
- update all backends

Add Cryptonight-fast - Masari PoW variant

- rename cryptonight_fast to cryptonight_masari
- set dev pool to cryptonight_monero

increase version to 2.4.4

fix broken AMD APP SDK download links

remove definition of `_mm256_set_m128i`

fix duplicated nonce usage

AMD has removed the AMD APP SDK links from the website. The AMD employes in the AMD formum posted links to there Dropbox where the SDK can be downloaded)

version prepere for the next release

The define of `_mm256_set_m128i` is not needed and avoid intel compiler throws a warning about it.

- avoid that a nonce which not fits to the current job is used (check jobId after start nonce is consumed)
- move jobId check into the if condition to get a new bunch of nonces
- CPU: add jobId validation after the start nonce is consumed

fix possible deadlock with Volta

Update for CUDA 9.2 Toolkit

Add options to set wait/work time for benchmark

avoid out of order job processing

The login result of a pool contains the first job for the miner.
In the case where the pool is sending very fast after the pool login result
a new job it is possible that the newer job is processed faster than the job within the login result.
The result will be that the miner is mining an older job instead the newest (last received).

- enumerate all received messages
- trace the message id of the last procssed job
- skip all jobs where the message id is older than the last procesed id

fix job consume

If CUDA 9.X is used and the miner is compiled for `sm_70` and used with Volta GPUs than the miner
deadlocks if `threads` is not a multiple of `32`.

- use `__activemask()` to get all active lanes

- reformat `read_write_lock.h`
- fix spelling issue
- move job id increase of the write to the buttom

user read write locks to be sure that no job is consumend during the job update