OpenCL: add strided_index 3

Add new striding index where the memory is chunked by the size of the work group (worksize).

Co-authored-by: SChernykh <sergey.v.chernykh@gmail.com>

OpenCL: cnv8 optimization

OpenCl: optimize cn-v8 div

AMD: use more 32bit operations

OpenCL reduce API overhead

small optimization for non cryptonight_v8 algorithms

OpenCL: optimize cn-heavy div

- optimize division

CUDA: reduce cn-v8 shared mem footprint

OpenCL: reduce local mem footprint

CUDA: optimize cn-v8 div

optimize cryptonight_heavy diff

- change a few 64bit variables into 32bit.
- provide defines type quallified

CUDA: optimize cn-heavy div

- remove useless `clFinish`
- avoid download num threads for skein&co and start always as much threads as in all other kernel (terminate useless threads)

Reduce local memory foot print to increase the occupancy.

Co-authored-by: SChernykh <sergey.v.chernykh@gmail.com>

port optimizations from OpenCL.

Co-authored-by: SChernykh <sergey.v.chernykh@gmail.com>

Use only the half AES matrix and compute the other half in place.
This PR increases the possible occupancy.

port OpenCl optimized division to CUDA

Co-authored-by: SChernykh <sergey.v.chernykh@gmail.com>

change load order for backends

Topic amd refactoring

If CUDA is loaded before AMD but no CUDA is available it can be happen that the embadded OpenCL code is empty.
This is only an issue if the binary is builded static on a different system.

define shared memory in the outer scope

x-ref: https://github.com/xmrig/xmrig-amd/pull/192

- optimize kernel cn0 and cn2
- optimize vast int math
- use more 32bit variables

Co-authored-by: psychocrypt <psychocryptHPC@gmail.com>

version increase to 2.6.0

bumo version for next release

AMD: speedup cryptonight_heavy division

(doc/compile) Add better CUDA SDK vs Driver information

optimize the devision in cryptonight_heavy and cryptonight_haven

import of https://github.com/xmrig/xmrig-amd/pull/185/commits/5d9b9334654df25cea7707f667990fd1577ed290

update version to 2.5.2

NVIDIA: fix wrong number of threads

Update for upcoming Graft CNv2 fork

In the cuda backend for monero we start always twice as much threads as needed.
Those threads are than removed after the AES matrix is copied to the shared memory.
Never the less it is the result of an copy past bug.

- start correct number of threads for `monero`

Add console warning on GPU error.

Co-authored-by: Hans Kristian Rosbach <hk-git@circlestorm.org>