Review math inlining

[kpreid]

In commit 45a772d I split the math and raycast code into a new library crate, all-is-cubes-base. Unfortunately, I didn’t think at the time about the effect this would have on function inlining. rustc currently has a heuristic for marking small functions inlinable, but it doesn't seem to suffice. After a slapdash addition of #[inline] where it seemed like it would make sense, I get the following notable results in benchmarks:

Bench target	Benchmark name	Effect of inlining on run time
space	space-bulk-mutation/*	-0%..-96%
space	GridAab/iter_for_each	-42%
save	load	-21%
mesh	block/*	-10%..-26%
raytrace	threaded/*	+20%..+29%
mesh	space/*	+7%..+41%
block	evaluate/*	+16%..+56%
raycast	many steps *	+85%

Benchmarks run on my laptop have quite unstable results, but these are huge differences which I am confident are significant. But since they are differences in both directions, we need to break down the #[inline] changes into smaller units to determine what's actually improving performance and what's making it worse.

[kpreid]

The above data was collected by running all benchmarks only once. On re-testing, it seems that a lot of the apparent losses (and gains) may have been noise. Sigh.

[kpreid]

5c90bca puts in the rest of the inlining. In the end, I couldn't find any consistent regression.