Add a "processing" module

About

This MR is an internal refactoring, which adds a new nabu.processing module.

The aim is to have a more consistent modules breakdown.

Close #445 (closed)

The logic is the following:

• What stays in {cuda|opencl} are classes/functions which interface with pycuda/pyopencl, and do not provide actual processing. The typical examples are XXKernel and XXProcessing
• What moves to nabu.processing are classes providing an actual image processing operation, with (a) a base class (+ possibly reference implem), (b) a cuda backend, (c) an OpenCL backend. Examples: unsharp.py, unsharp_{opencl|cuda}.py
• Importing from nabu.{cuda|opencl} can fail if __has_{cuda|opencl}__ is False
• Importing from nabu.processing should never fail (it uses __has_{cuda|opencl}__ guards)

To do

• Move stuff from nabu.misc
• Deprecation warnings
• Fix internal imports (also in tests)
• Augment XXProcessing to have utilities like kernel(), dtype_to_ctype, etc
• Ensure that importing nabu.processing.xx doesn't fail (use __has_{pycuda|pyopencl}__ in these modules)
• Unit tests
• Update changelog/documentation
• End-to-end reconstruction test