u3: optimizes u3i_edit (nock opcode 10)

[joemfb]

This PR ports urbit/urbit#6004. It is not urgent.

Benchmarking this against the old implementation would be worthwhile. It might also be worth inlining/decomposing u3a_is_mutable(); this is (currently) its only call-site, and the road pointer and seniority predicate cannot change throughout this loop.

[ashelkovnykov]

This PR came up today during a sync between @joemfb and I. I skimmed it to make sure I understood the motivation and how it spiritually aligns w.r.t. similar noun walks in Ares, but I didn't verify the logic carefully enough to really "review" it.

[joemfb]

I've written a benchmark for this code, and run the various versions of this operation through it. The benchmark constructs a list of 1s, and then edits the list at the axis of each item, replacing the 1 with 2. This is an absurd operation, and no real-world code we ever run would look like it. But it's the best-case scenario for certain optimizations here, and gives us an opportunity to compare them:

opcode 10 variation	1k list	10k list
develop (a244cc5)	19ms	2.41s
^ without mutation (a6debdb)	26ms	3.218s
loop (d6988e6)	1ms	147ms
reduce branches (fa84fd8)	1ms	170ms
inline axis bit-math (e182de8)	1ms	159ms
^ without mutation	6ms	667ms
inline axis without branch reduction	1ms	130ms

Notably, the mutation optimization (we can edit a cell in place if it is on our road and has a refcount of 1) is only a ~30% improvement with the old implementation, but is a 5-6x improvement in the new.

I suspect that the branch reduction being slower is an artifact of this benchmark -- we're almost always editing the tail of a cell (lists associate to the right), making branch prediction very effective. So I've left it in for now, but I'm open to being talked out of that.

[ashelkovnykov]

Re-reviewed later, and then just now w/ Joe