Fixed quite a serious bug in FilterHotPixel.

This code is tricky because of 'scaler'. In the additions to hitmap this is handled correctly,
by only adding "1/scaler" of an event each time. However, nevent is incremented by 1 every time.
It should only be imcremented by 1/scaler, otherwise when you divide by it to get the frequencies,
you're dividing by too much.

So the hot pixel threshold was potentially 15 times smaller than what we thought it was.

On a related note, FilterHotPixel must run over a large number of events to work.
For example, if the threshold is 0.001, that means if a pixel fires in more than 1 in 1000 events,
it's 'hot'. So if FilterHotPixel is only run on 1000 events, every hit pixel will be 'hot'.
In my experience, the larger the number of events used, the smaller the number of hot pixels.

Therefore I set nevents in FilterHotPixel to be -1. I think this is the safest way to do it.

Further thoughts (second commit):
After performing a toy study, I found that for a threshold of 0.01
and with 60 pixel hits in each unique event, 600 unique events must be considered
to accurately find hot pixels, and not accidently call pixels 'hot' due to
statistical fluctuations. See plot.

As we have scaler 15, this means 10,000 data events sould be used as a minimum
with threshold 0.01.

I added this over-ride in FilterHotPixel, and also set the threshold to 0.01 in
pyEudetReconstructionOnly.py.

Note, if the threshold is lowered then even more events must be used to determine
hot pixels

![hotpixelprob_toy_log](https://cloud.githubusercontent.com/assets/8256377/3856987/cebc9a36-1efe-11e4-87c9-b06dd69246c6.png)