Remove ordered mailbox and rename priority to unicast

[thomaseizinger]

This aims to resolve #94 by renaming split_receiver to detach. This wording has prior art in the ecosystem, for example:

• https://docs.rs/smol/1.3.0/smol/struct.Task.html#method.detach
• https://docs.rs/tokio/1.32.0/tokio/task/join_set/struct.JoinSet.html#method.detach_all

Both of these are about "running a task in the background".

As a 2nd step and with the terminology resolved, we remove the ordered mailbox and rename the priority one to unicast as a counterpart to broadcast.

[Restioson]

Happy to merge when passing CI - I assume will need rebase from master.

Thinking about this again with fresh eyes, I think it really does make a lot of sense. I'm not sure if this was said by either of us before, but this kind of mimics atomics in some way (?). At least, that's how my mental model for this is now.

If you have two threads which are doing atomic operations on the same thing, the order of their atomic operations relative to eachother, if they are both using relaxed orderings, will be unspecified. They will happen, but they could interleave arbitrarily. The compiler is also free to rearrange operations on that thread.

Previously, ordered sends worked the same, except that operations on one thread would still be ordered. This is nice, but as we've discussed can lead to backpressure footguns and is also harder to support. Plus, it's possible to emulate previous behaviour with new behaviour: you could always

// look ma, like `detach` but with multiple messages
tokio::spawn(async {
    addr.send(1).await;
    addr.send(2).await;
});

though the above wouldn't wait for the first to be sent before queuing the next (wonder if this is an issue)? Do you still even care about the back-pressure of mailbox size being exerted on the sending task if using detach?

[thomaseizinger]

Thinking about this again with fresh eyes, I think it really does make a lot of sense. I'm not sure if this was said by either of us before, but this kind of mimics atomics in some way (?). At least, that's how my mental model for this is now.

I am glad that we arrived at this! I agree with the atomics view. The similarity is not surprising when you think about it: Address is a way of writing to an actor without requiring &mut self and thus requires some kind of interior mutability.

[thomaseizinger]

@Restioson I had to adapt a few tests, please have a look!

[Restioson]

side note: it's funny how many async crates we're mixing and matching here, haha