[Feature Req] Consider using nu instead of m as integration variable

[steven-murray]

Is your feature request related to a problem? Please describe.
When integrating over the mass function, it is usually more robust to integrate over nu instead of m. Otherwise, it can be
hard to ensure convergence at either the lower or upper end.

Describe the solution you'd like
This is by no means clear. Typically, if you want dndm, you're kinda thinking in mass-space (I want dndm at mass m). So there needs to be a way to specify the vector based on mass. But when integrating over mass (eg. ngtm or any halo model quantity) we care more about converging at either end, and it would be more useful, probably, to be able to specify in terms of nu.

Potentially, we want a new framework that specifically takes care of integration over mass/nu. This class would then take care of ngtm and friends. You'd specify the limits in nu to this class, and mass would be a derived quantity. There may be some API kinds of problems here. What if the user wants ngtm at the same masses as dndm, and they want dndm at log-spaced masses? They'd have to interpolate ngtm and evaluate it at the masses of a different framework? Is this even something that anyone would want?

Also, there's the issue of how to re-use the existing MassFunction framework in the extended framework, so we don't have to implement calculation of mass given nu. Would the mass function be a subframework? But then would we kind of circuit it so that you use it to get nu(m), then invert to get m(nu), then pass those masses back into MassFunction? Seems convoluted and brittle. Or do we just add the option to specify the mass vector via nu in MassFunction? This seems somewhat simpler.

Describe alternatives you've considered
A possible alternative (or even something to try anyway) is to use backend tables and splines for all quantities. We could then provide functions that interpolate over nu and m. We could control the range of m/nu in the background and ensure it's large enough. This also means the user could call the mass function at irregularly-spaced m, or a single m. This is attractive, but not necessarily efficient or simple. Splines are headaches at the best of times. It's not direct -- calculations are happening that the user doesn't necessarily need (what if they only ever wanted to calculate dndm for a few masses... why then do it for all mass?).