Remove Copy/Clone from MutableHandle

[gmorenz]

Fixes #520

Replaces Copy and Clone with a reborrow method that handles lifetimes correctly. Also merges wrappers and jsapi_wrapped since they now have the same API.

As discussed in #520 there are multiple options here, with no clear "best option". I currently favor this since

• There's enough complexity in how data is accessed through RootedGuard that safe-interior-mutability apis are likely to be unwieldy (these would let us keep Copy/Clone.
• It feels like the least "weird" of the other alternatives.

Accompanying servo branch here.

This doesn't fix JS::MutableHandle being Copy and Clone. JS::MutableHandle doesn't carry a lifetime annotation, so there's no reasonable way to define reborrow on it. The fix here is probably to remove the Deref and DerefMut impls on it (since without lifetime annotations there's no way those are safe functions) and move servo to always using the lifetime annotated versions.

It also doesn't fix other aliasing issues surrounding this type, those can/should be fixed separately, and apart from an approach that leans entirely into interior mutability, those fixes should be compatible with this change.

[gmorenz]

A previous version of this change is here, with an accompying servo branch here.

It took the approach of passing around &mut MutableHandle instead of explicit reborrows. I decided that I didn't favor that approach because the extra temporary variables felt like more of a compromise than the explicit reborrow calls. The explicit reborrow calls are also more like clone and perhaps easier to teach.

That branch also includes a commit removing Deref[Mut]. The new branch does not as that can be done as a separate change - though at least removing the DerefMut impl is going to be required to fix other aliasing issues with this api.

[gmorenz]

Marking this as ready for review with my preferred fix to #520. The design question asked in #520 is still valid, and if we'd rather go another way... this shouldn't be merged as is (though it wouldn't be hard to revert).

I'm also going to open a draft servo PR simultaneously. I'm not sure what the preferred procedure for updating mozjs and servo in lockstep is? If that's a process we'd really rather avoid, this could be split into two. First add reborrow. Then update servo to use it and to use wrappers apis. Then drop Copy/Clone and the jsapi_wrapped modules here in a subsequent commit.

[mrobinson]

I'm also going to open a draft servo PR simultaneously. I'm not sure what the preferred procedure for updating mozjs and servo in lockstep is? If that's a process we'd really rather avoid, this could be split into two. First add reborrow. Then update servo to use it and to use wrappers apis. Then drop Copy/Clone and the jsapi_wrapped modules here in a subsequent commit.

Typically what we do for stylo is to post the stylo PR, and then post the corresponding Servo PR (with a temporary change to Cargo.toml to override the stylo git ref to the PR commit). Once both PRs are approved we merge the stylo one first and then undo the temporary change to Servo's Cargo.toml, update stylo in Cargo.lock, and then merge the Servo PR.