WrappedObject/Object/NativeMethod aren't genuinely Sync #366

This issue is born out of my comment on #324 about NativeMethod.

NativeMethod does not have type bounds enforcing that its contained closure is Send. Therefore Object and WrappedObject can't be Send either.

To avoid cluttering #324 - there's actually a reasonably straightforward fix for FixedRegisters, I'm going to continue the NativeMethod discussion here.

Firstly, should we allow non-Send NativeMethods for NoSendInterpreter? My feeling is yes, we should. It stands to reason that if you're using a non-Send interpreter you have a good reason for that, so we should accept closures that work with the types you're using.

Secondly, how?

The fact that WrappedObject can contain a NativeMethod (via Object), and NativeMethod refers to WrappedObject means there's effectively a cycle in type references.

I can think of three ways:

1. Deal with horrendous generic types and bounds - I don't think there's a straightforward way of limiting the generic types, they'll touch pretty much every other type in the crate. I'm still not entirely sure it actually is even possible, because of the cycle in type references.
2. Remove NativeMethod from Object completely. Then Object is effectively AmlObject, we'd need a NonAmlObject to hold NativeMethod and anything else we think of in future. Plus wrapper types that could hold either.
   • This would allow objects to be passed between two different interpreters, as they could be now.
3. Turn NativeMethod into a kind of index - perhaps an AmlName, or even just an integer - then store the actual closures in a map in the namespace.
   • In this case, objects are less easily passed between two interpreters, as the NativeMethods would be different.
   • I haven't fully worked out how any reference counting would work to ensure the closures are freed when needed, but it seems tractable.

I'd probably go for option 3, since it reduces the distinction between NativeMethod and other object types. This hopefully makes it less likely we'd introduce bugs related to it in future.

But thoughts from @IsaacWoods and anyone else interested are most welcome.