Update pre-computed constexpr Gauss and Gauss-Kronrod constants

[jzmaddock]

to always store literal types.
Fixes: #1077.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (ca29a70) 85.21% compared to head (b2b839a) 84.90%.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #1079      +/-   ##
===========================================
- Coverage    85.21%   84.90%   -0.31%     
===========================================
  Files          879      880       +1     
  Lines        66880    67275     +395     
===========================================
+ Hits         56989    57120     +131     
- Misses        9891    10155     +264     

Files	Coverage Δ
include/boost/math/quadrature/gauss.hpp	65.03% <100.00%> (-25.10%)	⬇️
include/boost/math/quadrature/gauss_kronrod.hpp	49.31% <100.00%> (-45.90%)	⬇️
test/git_issue_1075.cpp	100.00% <100.00%> (ø)

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ca29a70...b2b839a. Read the comment docs.

[SteveBronder]

How would you feel about something like the below? I wrote a is_constexpr_constructible() function that is used to deduce which gauss_detail to use. If Real's constant type is constructible from a long double at compile time (which I think is true for float, double, and long double) then it uses the one that is constexpr. Otherwise it uses one that constructs the values at runtime.

Looking at the version here I think something bad would happen across if we ran this once, cleaned up the arena, and tried running again. I'm always bad at the intricacies of static types in functions, but if they are declared once for the life of the program and we clean up the memory arena then I think the next time we run this the program would do UB accessing memory that has been cleaned up or reallocated.

https://godbolt.org/z/j1br4GTno

EDIT: updated link to compile with c++14

[SteveBronder]

Just a few small comments. I'm not really following how this fixes #1077

[jzmaddock]

I hope this should be good to go: @SteveBronder can you try this PR against your actual code?

[SteveBronder]

Thanks I'll give this a whirl on Monday!

[SteveBronder]

This works!

[NAThompson]

@jzmaddock : Looks like the build failure is unrelated-want to merge?

[jzmaddock]

Looks like the build failure is unrelated-want to merge?

Yup, merging...