opencl: Store oclthreads and only convert to/from intensity numbers when dealing with external interfaces
opencl: Support for setting oclthreads as xintensity

Xintensity interface is credited to ArGee of RGMiner.

This new unit is designed for a much finer grained intensity setting and also opens up for dual GPU threads on devices not previously able to. Note: make sure to use lower thread-concurrency values when you increase threads.

Intensity is currently used to spawn GPU threads as a simple 2^value setting.
  I:13 =    8192 threads
  I:15 =   32768 threads
  I:17 =  131072 threads
  I:18 =  262144 threads
  I:19 =  524288 threads
  I:20 = 1048576 threads
Notice how the higher settings increase thread count tremendously.

Now enter the xintensity setting. It is simply a shader multiplier, obviously based on the amount of shaders you got on a card, this should allow the same value to scale with different card models.
   6970 with 1536 shaders: xI:64 = 98304 threads
R9 280X with 2048 shaders: xI:64 = 131072 threads
 R9 290 with 2560 shaders: xI:64 = 180224 threads
R9 290X with 2816 shaders: xI:64 = 163840 threads

   6970 with 1536 shaders: xI:300 = 460800 threads
R9 280X with 2048 shaders: xI:300 = 614400 threads
 R9 290 with 2560 shaders: xI:300 = 768000 threads
R9 290X with 2816 shaders: xI:300 = 844800 threads

It's now much easier to control thread intensity and it potentially allows for a uniform way of setting the intensity on your system.
opencl: Change xintensity interface to simply intensity=xNNN (and allow setting d<whatever> for an initial dynamic intensity)
opencl: Redo Manage TUI detail line to use xintensity when more reasonable
opencl: Make current intensity, xintensity, and oclthreads available via RPC
opencl: Deprecate all dedicated commandline options for parameters accessible via set_device