crop_cube() very expensive

[georgedorn]

I've done some profiling runs to see where the most time is spent. In the main (mikepound) branch, 8% of the runtime for n=9 is spent within the crop_cube() function. In my merged branch, containing both my PR and @bertie2's PR, it's 18% of runtime, due to the biggest offender (rle()) being called less and executing faster.

It's the next logical step to attempt a speedup. I think the best path here is that rather than cropping naively, track where the new cube was added and crop where we know we only added 0s. This saves us from iterating over every cube in a side before deciding to trim it. This won't be easy and expand_cube() probably won't end up with as clean an implementation.

[bertie2]

significantly improved by @ana-096 at #11

[mikepound]

@georgedorn As per a discussion I was having with @bertie2, I've created a new repo which will host the community changes to this code, to keep this version in line with the original video. Are you interested in being a maintainer on this other repo? I expect no commitment :) But this could be a good way of letting people contribute code without everything going through me, which will likely be an extremely slow process!