Allow #[cppgc] &mut T in sync ops

[littledivy]

Allow #[cppgc] _: &mut T and #[cppgc] _: Option<&mut T>

Closes #787

Trying to use it with async op gives a compiler error:

error[E0308]: mismatched types
    --> core/runtime/ops.rs:1911:3
     |
1911 |   #[op2(async)]
     |   ^^^^^^^^^^^^^
     |   |
     |   types differ in mutability
     |   arguments to this function are incorrect
     |
     = note: expected mutable reference `&mut TestResource`
                        found reference `&TestResource`
note: associated function defined here
    --> core/runtime/ops.rs:1911:3
     |
1911 |   #[op2(async)]
     |   ^^^^^^^^^^^^^
1912 |   pub async fn op_test_set_cppgc_resource(#[cppgc] resource: &mut TestResource, value: u32) {

[littledivy]

TODO: add v8::cppgc::InnerMember::as_mut in rusty_v8

[bartlomieju]

LGTM

[lucacasonato]

I am not clear as to the safety of this. For example, this is currently valid but very unsafe:

#[op2(async)]
async fn op_use_cppgc_object_mut_async(#[cppgc] _wrap: &mut Wrap, #[cppgc] _wrap2: &mut Wrap) {}

When called with the same object for first and second argument.

[lucacasonato]

This is not safe anymore. Please now mark as unsafe. The caller has to guarantee that there are not more than one user currently called try_unwrap_cppgc_object on this object.

[littledivy]

I'll add an unsafe variant that returns &mut

[lucacasonato]

      _ => Err(ArgError::InvalidCppGcType(stringify_token(*of.elem))),

[lucacasonato]

This should also not be allowed on #[op2(reentrant)] (that would be unsafe).

I think we should revert this for now - it's not clear to me how to make this safe yet, and what restrictions we need. We should talk about this more.

Also, for such fundamental issues we need more than one review. These are incredibly delicate components of our stack, and they need to be very well audited, especially when involving unsafe code.