update chunksize test to make it faster - and RT minor perf improvement

[erwanp]

@sagarchotalia I realized the test implemented in #488 was extremelly slow on Travis-CI (few minutes)
Here is a small update to make it faster (~10s).

Please review.
Please also comment if needed, it's a good way to learn more about the codebase.

I'll ask you to update this PR and also make sure that the Number of chunks in the "chunksize" mode is different from 1, else we're actually computing all lines together and not testing correctly.

---

Other minor changes :

• add config parameter "RESAMPLING_TOLERANCE_THRESHOLD" to deal with resampling errors globally
• add copy_array=False option in s.take(), improve MergeSlabs performance by using it

[codecov-commenter]

Codecov Report

Merging #503 (1a9abf2) into develop (b54be7b) will decrease coverage by 0.03%.
The diff coverage is 68.42%.

@@             Coverage Diff             @@
##           develop     #503      +/-   ##
===========================================
- Coverage    73.35%   73.31%   -0.04%     
===========================================
  Files          138      138              
  Lines        18979    18958      -21     
===========================================
- Hits         13922    13900      -22     
- Misses        5057     5058       +1     

[sagarchotalia]

Hello, this looks great to me! I'll add the number of chunks parameter by explicitly calculating the "N" parameter in the code and asserting that N>1, if that's okay

[erwanp]

In production, having N=1 (i.e. all lines processed at once) is not necessarily a problem; so it should remained allowed.

But in the test it's very important we're having N>1. You could store N as a hidden variable in the SpectrumFactory; sf._Nchunks for instance, and evaluate this in the test()