[enhancement] Allow cross-activation ordering constraints on side-effecting operations in procs

[ericastor]

What's hard to do? (limit 100 words)

Write a proc with specified ordering of I/O operations between activations; e.g., a proc that does thing A followed by thing B, and does not allow the next activation of thing A to run in parallel with the first activation of thing B.

Currently, there's no safe way to instruct XLS not to allow parallel execution of these operations as the next activation moves down the pipeline.

Current best alternative workaround (limit 100 words)

Add a state parameter that is an unremovable data dependency of "thing A", and make sure we can't determine its value until "thing B" is completed. This varies between difficult and impossible to do safely, as future optimizations may be able to see through the meaninglessness of this state parameter.

Your view of the "best case XLS enhancement" (limit 100 words)

Allow users to connect operations between activations with "tokens" - unremovable dependencies that contain no actual data. Note that order-sensitive side-effecting operations already return these in the IR and DSLX. If we could pass these on to the next activation in a way that XLS respects, this would suffice to let users specify cross-activation ordering restrictions as well.