Allow for option tolerance for SSTs and seaice fractions

[mathomp4]

Runs by @acollow using the CERES SSTs and ice fractions were triggering the protections against FR being less-than-zero or more-than-one.

Further tests confirmed this and by using wide prints it was found that the files seem to have values juuuuust bigger than one:

$ rg fracice allieSST-2023Sep18-1day-c90-OPSEmiss/1day.prints.precision.out
2205:[45] FRACICE:   0.000000000000E+00  1.000000119209E+00
2223:[48] FRACICE:   7.207512855530E-01  1.000000238419E+00
2224:[50] FRACICE:   2.898840308189E-01  1.000000238419E+00
2225:[51] FRACICE:   7.837977409363E-01  1.000000238419E+00
2226:[52] FRACICE:   4.546182751656E-01  1.000000119209E+00
2227:[53] FRACICE:   8.661046028137E-01  1.000000238419E+00
2239:[42] FRACICE:   0.000000000000E+00  1.000000119209E+00

My guess is these are due to how the files were made/processed values like this snuck in. The "right" thing to do is reprocess the files (in my opinion), but that is a lot of work and if someone has used them, well, we'd change the answers perhaps.

So, in consultation with @sanAkel, this PR adds the ability to "loosen" the restrictions on ice fraction. A new setting, STRICT_ICE_FRACTION is added which defaults to .TRUE. which mirrors the current handling. If you are above 1 or below 0, error out.

But, if you set that to .FALSE. then it allows for tolerance, ICE_FRACTION_TOLERANCE which in this PR is defaulted to 0.01. Then any values the code sees from 0.0-TOL to 0.0 are set to 0.0, and anything from 1.0 to 1.0+TOL are set to 1.0.

Note that unless you trigger this bug, this is zero-diff.