Added tests for existing math operators

[jkrude]

Tested StdLib-backend fully.
Tested Cuda-backend compiling.
Not tested Hip-backend.
Edit: Refractored Code according to https://github.com/ComputationalRadiationPhysics/contributing/blob/master/codingGuideLines/cpp.md.

[psychocoderHPC]

Thanks for your first PR. Only a few small changes are required

[BenjaminW3]

All the build jobs complain about some compilation issues. Are you working on it?

[tdd11235813]

Actually I do not really like the code because of the functions pointers (it is also not working).
When talked about a solution in the first time, we had arrays in mind to describe the set of functions.
The function pointers' host-device interoperability actually would require more dirty code (example) and it becomes more and more ugly and it is better to remake it in a good and functional C++ style now :)
(Edit: this is not the fault of @jkrude, I just did not have enough time to think about good design)

I discussed with @psychocoderHPC again, and that I like the simple row-wise-like enumeration of the related math functions+range.
Functors would be more easy to handle for host-device compiling, we just need a way to compact code, so one does not have to write dozens of functor boilerplate codes.

// sketching a possible functor layout for math test
struct TestOpFoo {
  static constexpr Range range = Range::Unrestricted;
  static constexpr OpType optype = OpType::Unary;

  ALPAKA_FN_ACC
  template<typename T>
  auto operator() ( T arg1 ) -> T {
     return alpaka::math::foo( arg1 );
  }

  ALPAKA_FN_HOST
  template<typename T>
  auto expect( T arg1 ) -> T {
     return std::foo(arg1);
  }
};

// creating a tuple with all the Ops, passing it to single kernel
// OR using a compile-time foreach, invoking a kernel for each functor 
...

Then for each math function a functor has to be written and registered for the test kernel. Just need a clean way to compact functors and their processing ...

Btw, code-style should be discussed, too ( eg. curly braces for initialization, except for elemental types, where assignment is ok, like in for-loops ).

Edits: typo + edit after 1st paragraph

[tdd11235813]

re-written and pushed in #847 separately, so closing this.