simplify alpaka usage

[psychocoderHPC]

Motivation

Currently alpaka is hard to use because the user needs to know how all concepts e.g platform, accelerator, device, queue,... and how they are connected to each other and which concept must be used where.
I started a discussion in #944 to simplify the interface for alpaka.
This PR is introducing a full change of the usage, instead it provides the required trait specifications to allow the user a accelerator based programming. This means instead that the user needs to handle device and platform types he can use the accelerator to allocate buffers, query device information.
Before this PR the user got the device type from an accelerator and used the device type to get the platform. This explicit traversing over types with a 1:1 relation is removed by forwarding traits to the next hierarchy level when needed.

General Simple Workflow

1. define an accelerator type Acc
2. get the device instance based on Acc
3. use Acc to create buffers

Changes

• accelerator
  • specialize platform traits to query device information (redirect to
    platform trait)
  • specialize buffer for accelerators
• device
  • add concept ConceptDev
  • specialize DevType for a device
  • specialize platform traits to query device information (redirect to
    platform trait)
• mem
  • Buffer and views not using the template parameter TDev directly.
    Instead TDev is handled as concept and the device type is first
    evaluated.
• Use the simplified accelerator centric view for all examples.

[bertwesarg]

Hi, nice simplification. One question though, why not moving alpaka::pltf::getDevByIdx into alpaka::getDevByIdx or some other name space? This way, the term `pltf' should be completely avoidable.

[psychocoderHPC]

Hi, nice simplification. One question though, why not moving alpaka::pltf::getDevByIdx into alpaka::getDevByIdx or some other name space? This way, the term `pltf' should be completely avoidable.

I like that idea. This will than also mirror the fact that getDevByIdx, getDevCount can be used with different concepts.
We can make another PR if this gets excepted.

[BenjaminW3]

I like this version. You are passing in something (TDev) that can give you the real device type via alpaka::dev::Dev<>. This extends the valid types easily.
If it is already a device, it uses the reflexive alpaka::dev::Dev<> specialization of the device type itself.
If it is not a device, it simply has to have a specialization of alpaka::dev::Dev<>.

[BenjaminW3]

I would prefer if we could get rid of those specializations here.
We should do the same that is done for the Buffer (if possible).
May we change the implementation of the trait accessor methods below?
Instead of calling traits::GetDevCount<TPltf>::getDevCount() they could call traits::GetDevCount<alpaka::pltf::Pltf<TPltf>>::getDevCount().
The platforms would need a reflexive specialization of the alpaka::pltf::Pltf<> trait and the device already has a alpaka::pltf::Pltf<> specialization.

[BenjaminW3]

@psychocoderHPC I have pushed a simplification of your simplification onto your branch. So nothing to do for you anymore ;-)

[psychocoderHPC]

@BenjaminW3 From my side the changes looks good. We should check if it is useful to add self reflection also to other traits e.g. QueueType in a separate PR.