FIREFLY-1923: Fix inability to load large FITS tables

[loitly]

https://jira.ipac.caltech.edu/browse/FIREFLY-1923
https://jira.ipac.caltech.edu/browse/FIREFLY-2047

FIREFLY-1923:

• FITSTableReader: replaced getRow()'s per-cell reflection-based type
  dispatch (getValAsObject(), nRow x nCol times) with getColumn() based
  reads that resolve dispatch once per column instead.
• deg2pix: remove NaN, clamp jp/jm to [0, nside) on both bounds (fixes left-shift overflow)
• decimate_key/decimation stats: guard NaN and +/-Infinity, not just NaN
• test file: It's over 3GB. Trey has one. Let me know if you need me to provide it.

FIREFLY-2047: Improve decimation handling of non-finite values

• throw a clear error when a column has no finite values
• exclude merged invalid-rows bucket from decimated output
• test file: https://caltech.box.com/s/ybh6b19pnb02a0dxqtzg5dwpk7p1czcu

Test: https://firefly-1923-2047-nan-values.irsakubedev.ipac.caltech.edu/firefly/

[robyww]

I looked a FITSTableReader pretty closely. Your changes look good and help improve speed. However, I think you need to put hduTable.getKernel() back in the code. I did several test with the SPLICES file. getKernal seemed to improve performance by about 30 seconds. Surprisingly the memory consumption is about the same. getKernal seems to grab more memory upfront but by the end both ways use the same amount. That is consistent with my experience with the FITS library. It attempts to cache HDU memory.

[loitly]

put hduTable.getKernel() back in the code. I did several test with the SPLICES file. getKernal seemed to improve

Both hduTable.getKernel() and hduTable.getColumn() load the entire table into memory. I’m surprised that their performance differs. I’ll test it again.