New Plugin: Phase Space

## Introduction

This plugin introduces a live [phase space](https://en.wikipedia.org/wiki/Phase_space#Examples) analysis. The originally 6D phase space is the friend of every physicist and is spanned by the 3 spatial coordinates and the 3 momentum coordinates. That itself sound super complicated but opens a wide area of possible observations. There are, for example, certain basic rules that apply to *volumes* defined in this 6D world, see e.g. [Liouville's Theorem](https://en.wikipedia.org/wiki/Liouville%27s_theorem_%28Hamiltonian%29), the [Ergodic Hypothesis](https://en.wikipedia.org/wiki/Ergodic_hypothesis) or enjoy what a physicist describes as [*Chaos* !!11elf](https://en.wikipedia.org/wiki/Phase_space#Chaos_theory).

Well - awesome! 6D! But... that isn't it. Lucky enough there are certain systems, mainly depending on their symmetry, that obey the before called theorems even for a reduced plane in the phase space. This plugin calculates user defined planes like *x-px*, *x-pz*, *z-py*, *you-name-it* for live output to give a first insight into a system without crunching the whole raw data in post-processing again.

### How does the implemented algorithm work?

We want to have an image like this:
![0_phasespace_left](https://cloud.githubusercontent.com/assets/1353258/2697824/ed85285a-c3f2-11e3-8c0e-98d44631d7c2.png)

but it's data is distributed on the following nodes in real-space:
![0_phasespace_right](https://cloud.githubusercontent.com/assets/1353258/2697737/ccb503f8-c3f1-11e3-912b-6792002e2b2b.png)

we now choose the *spatial axis* of our phase space that we want to calculate (let us use *y-pz* for now), so it is *y*. The problem now is, that the *pz* (the z momentum component) can reside on all the following nodes:
![01_phasespace_distr](https://cloud.githubusercontent.com/assets/1353258/2697829/f66f991e-c3f2-11e3-8e7d-bb070e074d9b.png)
![02_planes](https://cloud.githubusercontent.com/assets/1353258/2697744/e23a6416-c3f1-11e3-8c03-dee4fa45590d.png)

Every node now calculates his non-exclusive phase space on the y axis it participates by depositing the charge of the particle (or mass, or energy, or what one likes) in it. Now we reduce (add) this information *plane-wise*:
![reduction](https://cloud.githubusercontent.com/assets/1353258/2698571/fc3240aa-c3fb-11e3-8d7c-029f669b43f7.gif)

All non-root nodes can exit now, the left-over nodes on the corner do the parallel output.

### Does that work for moving window?

Yes, the root ranks might not stay at the real "corner" any more but as long as they stay *in line* and cover the whole phase space this does not cause a problem.

### Does that work for static load balancing?

Yes, for the implemented method [--gridDist](https://github.com/ComputationalRadiationPhysics/picongpu/blob/484ed7077f3838e857ce92c5b274e528443fd453/doc/TBG_macros.cfg#L75) this algorithm should work out too.

- [ ] to do: test this in run time again

### User Documentation:
For an introduction how to use it, please refer to its [wiki page](https://github.com/ComputationalRadiationPhysics/picongpu/wiki/Plugin%3A-Phase-Space).

### Dependencies:
- output in *parallel libSplash* format

### Current limitations:
- works only in PIConGPU 3D right now
- only one range per selected space-momentum-pair possible right now (naming collisions)
- charge deposition uses the *counter* shape for now (would need one more write to neighbours to get it correct to the shape)
- the user has to define the momentum range in advance
- the resolution is fixed to `1024 bins` in momentum and the number of cells in the selected spatial dimension

### Thanks

Thanks to @Heikman for the introduction in *cuSTL*, the initial hacking support and bug fixing. Thanks to @psychocoderHPC for the pointers during rebase.