Migrate types from a macro to a trait

[tgross35]

This allows us to move a lot of logic out of macros and into generic functions, which is a nice cleanup and much better for usability.

[tgross35]

@beetrees I'm still working on some better naming cleanup / docs / comments, but you may want to take a look at this. Basically migrating from always relying on macro expansion to putting everything into a trait, which should help avoid string matching problems (like you pointed out on a different PR).

None of the possible refactoring of ULP / precision is done here.

[tgross35]

Let me know if you have any name suggestions too. I feel like too much here is some variation of "function" or "op", but I can't come up with anything much better.

[tgross35]

I still don't have great names but I added the following to hopefully disambiguate a bit

libm/crates/libm-test/src/op.rs

Lines 6 to 14 in 7c41830

	//! Basically everything could be called a "function" here, so we loosely use the following
	//! terminology:
	//!
	//! - "Function": the math operation that does not have an associated precision. E.g. `f(x) = e^x`,
	//! `f(x) = log(x)`.
	//! - "Routine": A code implementation of a math operation with a specific precision. E.g. `exp`,
	//! `expf`, `expl`, `log`, `logf`.
	//! - "Operation" / "Op": Something that relates a routine to a function or is otherwise higher
	//! level. `Op` is also used as the name for generic parameters since it is terse.

[beetrees]

I think the naming here is always going to be somewhat arbitrary, but I think what you've gone with is perfectly reasonable terminology (I don't have any unequivocally better ideas). The most important thing (which I can see you have done) is to make sure it's documented.