Update TRestDetectorSignalToRawSignalProcess to support calibration points and shaping

[lobis]

This PR updates TRestDetectorSignalToRawSignalProcess with the following:

• A new trigger mode "fixed" has been implemented, where the user can manually set the exact time of the first bien (instead of using the time of the first deposit).
  For example, a configuration such as

<parameter name="sampling" value="1us"/>
<parameter name="nPoints" value="512"/>
<parameter name="triggerMode" value="fixed"/>
<parameter name="triggerFixedStartTime" value="55.0us"/>
<parameter name="triggerDelay" value="100"/>

would have a starting time of 55.0 us - 1.0 * 100 us as it is affected by the triggerDelay parameter.

• A new parameter offset (fCalibrationOffset) has been introduced to allow for more calibration options besides the gain. This allows to set our zero elsewhere than on the middle of the range.
• A new way of calibration has been introduced which can be used as an alternative to the gain/offset. Instead of fixing the gain and offset (optional), we can specify two points to establish a linear relation between energy and ADC. For example:

<parameter name="calibrationEnergy" value="(0,10)MeV"/>
<parameter name="calibrationRange" value="(0.1,0.9)"/>

would generate a gain and offset such that 0 energy corresponds to 0.1 or 10% of our range (-32768 + 0.1 * 65535 in ADC units) and 10 Mev to 90% of our range. I believe this way is more intuitive and allows an easier reproduction of experimental calibration.

• Shaping has been implemented in TRestDetectorSignalToRawSignalProcess. Even though shaping is implemented already in rawlib (TRestRawSignalShapingProcess) it presents a few problems, mainly information loss when dealing with signals above the saturation limit.

The image below corresponds to the output of TRestDetectorSignalToRawSignalProcess after these changes. Note how some of the peaks are cut off due to saturation (as would happen on a physical experiment).

If we were to convert the detector signal into raw signal without the shaping, we would get something such as the image below.

If we were to perform shaping to this event, it would be impossible to get the first result, which is more physical, since the information of how much each signal is above the saturation limit is lost. We would get peaks with the maximum exactly equal to the saturation limit, which does not correspond to the physical event since signals with different energy would be exactly equal (such as the first peaks of green and yellow in the images).

[DavidDiezIb]

Great update @lobis, I only have one request: could you write these new options in the documentation? Few lines with the new keywords and an example would be great. Otherwise this will be hidden in the code for most of us and will be lost in time, like tears in rain ;)