New Node: FIFO Queue & FILO Queue

[BlueCyro]

Is your feature request related to a problem? Please describe.

I feel that FIFO/FILO queues are something that would be quite useful in protoflux. Right now we don't really have a way to temporarily store lots of values at once and release them sequentially on-demand.

Describe the solution you'd like

These queues would be able to accept object/value types and have the following inputs/outputs:

Input 1) Queue
Input 2) De-Queue
Input 3) Item to queue

Output 1) Passthrough "OnQueued"
Output 2) Continuation "OnDequeued"
Output 3) Output item for "OnDequeued"
Output 4) Number of items in queue

There could potentially be several types of these queues:

• One that acts as a "Data Model" queue, meaning data inside of it is synced
• One that acts as a "Store" queue, able to be read locally across contexts
• One that acts as a "Local" queue, existing only for it's context

For the "Data Model" and "Store" versions of this node type, Outputs 3 & 4 could be read persistently outside of impulses to "peek" how many items are in the queue, or what the next item in the queue is.

Describe alternatives you've considered

Local leaky impulse bucket doesn't carry any data, and the Delay With Data nodes only give you basic temporal control over what is queued inside of them (and require a new context per new item you want to "queue" - an awkward use)

Additional Context

Given that these queues are accessed sequentially, I feel we'd be able to implement them without collections as it stands currently. By nature, you're supposed to access queues one item at a time, meaning they don't arbitrarily access each element in any order other than their predefined sequences (FIFO/FILO)

Requesters

Cyro (Myself)

[JackTheFoxOtter]

I know this could be implemented without collection support, but those are basically push, pop and peek operations for lists, so I feel like it would make more sense to implement in a generic way as part of #572. Also, since these would likely be actions, they'd probably need a reference to a local / store / data model store of the stack, which would be a kind of collection data type, as well as an indirect variant for consistency.

[Frooxius]

This would be handled through the generic collection support, where we would add a number of collection types and operating with them.

We're not going to add this as standalone "ad hoc" node, since this can be better handled through general system - question here would be - why this one and not any others? What if other operations are needed and so on?