Change Allocated<T> in preparation for arbitrary self types

[madsmtm]

Arbitary self types (tracking issue: rust-lang/rust#44874) are not yet stable, but whatever form they end up as, we'll need to use a different type than Option<Allocated<T>>, since you can't (and won't be able to) use that as self: Option<Allocated<Self>>.

My proposal here is to introduce a new type, since we likely still need to be able to differentiate between "this type is newly allocated, and we don't know the nullability" (such as when sending to init methods) vs. "this type is allocated, and we know that it is non-null" (such as when receiving from init methods).

EDIT: See below for the alternative I'm going with.

[madsmtm]

I think there might be an alternative path:

We use struct Allocated<T>(Option<NonNull<T>>) everywhere, and then inside declare_class! when initializing instance variables, we do a NULL check to ensure that the allocation succeeded (e.g. we're not out of memory).

With a bit of macro trickery, inlining and LLVM optimizations, we can probably fairly reliably make it so that this NULL check is omitted when the declared method is called from Objective-C (since we know that receivers can't be null there), while still being included if someone initialize their instance variables outside of that.

Not sure if we want to base our design on non-guaranteed optimizations like this, though? On the other hand, initialization code inside declare_class! should be very linear with regards to Allocated, and OOM is a very, very rare situation (in contrast to e.g. initialization failure), so perhaps it's fine to hide it a bit more from our API?

I guess I'll have to experiment with it.

EDIT: See this gist (select "Show Assembly"), it seems likely that this idea will indeed work, so that's what I'll go with.

[madsmtm]

Another benefit is that also allows making convenience initializers every so slightly easier:

declare_class!(
   ...

    #[initConvenience]
    fn init_convenience(this: Allocated<Self>) -> Id<Self> {
        // Before
        let this = unsafe { msg_send![Some(this), init] };
        // After
        let this = unsafe { msg_send![this, init] };

        // Do something with `this`
        this.ivar = 42;
        this
    }
);

Which is important for extern_methods! and declare_class! being more symmetric (which in turn will make #455 easier to progress on).

[madsmtm]

Sadly, messaging init methods with the wrong return Id<R> compared to Allocated<T> (i.e. T != R) now gives worse diagnostics. I'm fairly sure this can be fixed, but it requires refactoring how message sending works (i.e. instead of using a trait, move MsgSendId to be inherent methods on RetainSemantics. Actually this has potential to improve diagnostics a lot).

But I'm going to go through with it anyway, the diagnostic is not that much worse.