Ionization in PIConGPU

# Ionizatiooooooon! :zap:  
-------------------------
Finally ... a working rudimentary version of ionization can be introduced to the PIConGPU project. This feature is yet unphysical because it makes use of an ionization model that was tailored to assure that one can check the number of particles that are created in the process. Still it features already all important mechanisms and lacks therefore only the physically field-tested ionization schemes.   

~~### IMPORTANT: Do not merge, yet because of perfomance issues with the trait `GetCharge()`   
The trait `particles/traits/GetCharge.hpp` had to be edited and now also needs the attribute `chargeState` in addition to `weighting`. So currently every particle has a `chargeState` and this is pointless e.g. for electrons.~~

-----------------
## The new feature includes: 
- [x] a new particle **attribute** `chargeState` 
- [x] a new **example** `LWFA_with_Ionization` 
- [x] an **ionization model flag** `particleIonizer< IonizationModel< SpeciesToBeCreated > >`
- [x] a simple ionization model `BSI` (Barrier Suppression Ionization) with **arbitrary** ionization threshold
- [x] a **fallback** for particle species without the ionization flag
- [x] **particle creation** during simulation runtime

## Features not included but yet to come:
- [ ] physical ionization models like `ADK`, real `BSI`, various field ionization models
- [ ] starting simulation with neutral atoms? (that might require much change)
- [ ] momentum conservation
- [ ] energy conservation with ionization current

## Future prospects:
- Multi-Photon Ionization for lower laser intensities
requires *field-to-photon-and-back* conversion :wink: @PrometheusPi 
- Impact- / Collision Ionization in cooperation with @mxmlnkn 


There is one problem if we join both lists.
It might be that both species had the same key (identifier) but with a different precision. (e.g. position<float_32> and position<float_64>)
- if we handle both as different keys than the user wondering why both particles has a different position
- if we copy it blind than we can get over or underflow of our float :-(