branch ris-custom-ramps contains edits to include CRNL and custom ramps

[thusharaprr]

The first set of edits is to include CRNL (a.k.a. FDNL a.k.a. reciprocity failure) using the galsim.detectors.addReciprocityFailure(exptime, *fdnl_params). The two-element fdnl_params argument can be specified using the new fdnl_params keyword argument of image.simulate() OR through **kwargs from another routine such as ris_make_utils.simulate_image_file(). In the process, I added the code to unpack the extra_counts arguments as well if it is passed through **kwargs. The code to include CRNL and quantize then quantize the image (as image objects should be at that stage) is contained within image.simulate().

The second set of edits allows the user to pass a custom image cube of shape (nreads, 4088, 4088) to image.simulate() using the keyword argument custom_ramps. This argument can also be passed from other routines that call image.simulate() through **kwargs. The user supplied custom ramps are then passed to l1.make_l1(), which passes them to l1.apportion_counts_to_resultants(). There, it is included additively read-by-read to "resultant_counts" along with "counts_so_far" and "instrumental_so_far". The new documentation, in all routines which have the custom_ramps keyword, encourages users to pass custom ramps of dtype 'i4'.

Currently, the use case for custom_ramps is the inclusion of the brighter-fatter effect (BFE). Although folks often talk about BFE as a PSF broadening, the change to the effective size of a star image depends on the charge accumulated in the affected pixels. Thus, as the name implies, sources with more charge accumulation will experience more broadening. Therefore, if BFE for stars is implemented by convolving with a kernel, different kernels will be needed for different stars within the same exposure. On the other hand, it is not obvious at all from first principles that BFE on extended objects can be treated as a PSF broadening. Therefore, the purest implementation of BFE is at the ramp level, where the charge accumulated in a pixel and its neighbors is assessed before every read, and the resulting changes to pixel charge accumulation rate are included for estimating the counts of that read. I have so far used custom_ramps to add a handful of BFE affected "bright" stars (mAB<17.5). Thus, the vast majority of pixels in custom_ramps are zero for every read. They are only non-zero in a handful of patches in custom_ramps surrounding the simulated bright stars. Those are the frames that get added to "resultant_counts".

I have tested the changes and made sure that the romanisim is completely unaffected when the keywords fdnl_params or custom_ramps are not used. When they are used, the code runs without additional warnings or errors.