OpenCLAllocator::copy() may call upload()/download() methods

remove 'dont_wait' (can be replaced with has_wake_signal)

* Extracted base64 persistence functionality

* Extracted YML persistence functionality

* Extracted JSON persistence functionality

* Extracted XML persistence functionality

* Extracted public C and C++ interfaces implementation in persistence

* Persistence: cleanup and fixes

* fixup! Persistence: cleanup and fixes

* Use Intel TBB's task arena if possible

OpenCV pthreads-based implementation changes:
- rework worker threads pool, allow to execute job by the main thread too
- rework synchronization scheme (wait for job completion, threads 'pong' answer is not required)
- allow "active wait" (spin) by worker threads and by the main thread
- use _mm_pause() during active wait (support for Hyper-Threading technology)
- use sched_yield() to avoid preemption of still working other workers
- don't use getTickCount()
- optional builtin thread pool profiler (disabled by compilation flag)

* persistence: replace arbitrary limit of cn to 4 by CV_CN_MAX

* python: added persistence test, remove temp files

* fixup! python: added persistence test, remove temp files

* fixup! python: added persistence test, remove temp files

- reduce scope of i,k,j variables
- use cv::AutoBuffer
- template<bool onlyDistance> class KMeansDistanceComputer
- eliminate manual unrolling: CV_ENABLE_UNROLLED

UMatData locks are not mapped on real locks (they are mapped to some "pre-initialized" pool).

Concurrent execution of these statements may lead to deadlock:
- a.copyTo(b) from thread 1
- c.copyTo(d) from thread 2
where:
- 'a' and 'd' are mapped to single lock "A".
- 'b' and 'c' are mapped to single lock "B".

Workaround is to process locks with strict order.

fix the "initializing global variables with values that are not
compile-time constants" issue in Intel SDK for OpenCL. The root cause
is when initializing global variables with value, the variable need is
compile-time constants.

Thanks Zheng, Yang <yang.zheng@intel.com>,
Chodor, Jaroslaw <jaroslaw.chodor@intel.com> give a help.
Signed-off-by: Liu,Kaixuan <kaixuan.liu@intel.com>
Signed-off-by: Jun Zhao <jun.zhao@intel.com>

* since #10231 opencv with instrumentation does not build

* kmeans: number of channels in _centers fixed

* fixedType() is checked now

* remove raw SSE2/NEON implementation from convert.cpp
  * remove raw implementation from Cvt_SIMD
  * remove raw implementation from cvtScale_SIMD
  * remove raw implementation from cvtScaleAbs_SIMD
  * remove duplicated implementation cvt_<float, short>
  * remove duplicated implementation cvtScale_<short, short, float>
  * add "from double" version of Cvt_SIMD
  * modify the condition of test ConvertScaleAbs

* Update convert.cpp

fixed crash in cvtScaleAbs(8s=>8u)

* fixed compile error on Win32

* fixed several test failures because of accuracy loss in cvtScale(int=>int)

* fixed NEON implementation of v_cvt_f64(int=>double) intrinsic

* another attempt to fix test failures

* keep trying to fix the test failures and just introduced compile warnings

* fixed one remaining test (subtractScalar)

  * stop re-enabling the warning C4127
  * disabling is done in CMakeLists.txt

- don't store ProgramSource in compiled Programs (resolved problem with "source" buffers lifetime)
- completelly remove Program::read/write methods implementation:
  - replaced with method to query RAW OpenCL binary without any "custom" data
- deprecate Program::getPrefix() methods

* fixed OpenCL functions on Mac, so that the tests pass

* fixed compile warnings; temporarily disabled OCL branch of TV L1 optical flow on mac

* fixed other few warnings on macos

Observed during launch of 32/64-bit applications on Windows.
Added '32-bit' prefix for 32-bit OpenCL devices. No prefix on 64-bit configurations.

This PR fixes incorrect division by zero handling in template
specialization of `Div_SIMD` for type `double`.