Proposal: Add support for priority messages to processes

[PastMoments]

Proposal:
Erlang/OTP has added priority messaging. There are various use cases, many detailed in EEP 76: "Long Message Queue Notification", "Prioritized Termination". In general, it can be a common pattern to send irregular messages. There were previous some technique with selective receives to temporarily skip messages (which gleam_erlang doesn't have). Meaning a user would need to write somewhat advanced erlang. Adding priority messaging would greatly reduce the complexity for users in these cases, as well as being more performant. It would also be useful to be able to make use of this feature with gleam_erlang's subject/selector system.

I propose a backwards-compatible addition to the API:

1. process.priority_subject() to create a priority subject, which is a value of the existing Subject type.

A priority subject would act identically to the a regular unnamed subject, with the following differences:

1. Creating a priority subject with process.priority_subject() will enable priority message reception on the owning process. (Possibly some performance penalty)
2. process.send will send priority messages, inserted in front of non-priority messages in the receiving process, but behind existing non-priority messages.

Selectors should also be able to select priority subjects as with any other subject, and receive/selector_receive will receive as with regular subjects, the only difference being the message order as noted above.

Why not a library?
One feature that would be difficult in a library would be to have Selectors to be able to seamlessly select both regular subjects and priority subjects. I have managed to do it, after some tinkering but it heavily relies on mimicking the internals of this library, and the internal structure of both Selectors and Subjects. Hence why I believe this functionality would be better integrated to this library fully.

Why not named priority processes?
Priority processes require you to pass an alias around (a reference), which isn't suitable for named processes (the premise being able to reference processes by name and not have to pass anything around).

Reference implementation #84

[lpil]

Thank you for the proposal! Could you please include your use case so we can understand what problem you have that this addition would solve. Thank you.

I'm also interested in what the advanced Erlang is that you mentioned that you are looking to replace in your project. Understanding that would be very useful.