Allow persistent active state for workers. #527
Description
Normally workers are set to active state when data is given and return to inactive state when it is returned. Workers are only given data when they are in an inactive state. A persistent worker (particularly gen) may want to decouple sends from receives.
This may be implemented by allowing data to be sent to a persistent worker while in an active state and maintaining active state, until persistency ends. These messages will probably be marked (possibly in libE_info) as active_recv messages or similar.
Such a message is only expected to be received by a persistent worker, and will either be combined with creating persistent state or, if received by libE_worker directly, will be thrown away (assuming the persistent sim/gen for which it was intended has exited persistent state).
This leaves the question of what happens in the case of a STOP (or other manager signal) being sent to the persistent worker. Either queued messages will be worked on until the signal is picked up, or either a buffering of incoming messages or other look-ahead capability is added). Relative order of signals and data messages may want to be kept, especially for example, in the case where one persistent worker is stopped (with thrown away messages) and another is started.
Consideration should be given to whether multiple received messages can be combined. This may have some non-trivial cases. Alternatively a non-blocking receive option could exist that would allow the gen func to control picking up of multiple messages.
Note that currently the worker receive is a blocking operation. Other operations are non-blocking (worker send + manager send and receive).