fix grey borders during stacking with output_norm

Fixes #1159 (closed): avoid changing the values which are at 0 (borders) when -output_norm option is set for the stack command. We also avoid using them to evaluate the min,max bounds of renormalization.

In addition, propose to change the behavior if output is in 32b (done in 2540aa4a):

• If output_norm, we keep the pixels as per stacking, irresp. of input images being 16b or 32b, the values will be renormed to [0,1] with norm_to_0_1_range
• Else we clamp in the [0,1] range

Later (tickets yet to be opened):

• add a way to specify 32b output if input is 16b without having to change the preference. Could be users are working in 16b for disk space reasons but could still benefit from stacking in 32b without having to go back and forth changing the pref.
• if working in 16b, the output_norm option has no effect. We don't really renorm in the [0,65535] range as the result of the stack is 32b and each pixel is converted back to 16b on-the-fly (we don't have a temporary 32b image onto which we compute the full image min/max, most probably to limit mem usage). Would require to change the mem requirement to hold a 32b copy of the image prior to renorm.
• pixel rejection calculation. Need to revisit how border pixels are accounted. When framing is max, the total number of pixels is huge and the real rejected pixels number can be small, resulting in a percentage close to 0 (to the accuracy we display).