There is an obvious race condition in window triggering

[solvicode]

When triggering windows that trigger algorithms with dependencies on past results, there is a clear race condition.

For example. Algorithm A gets triggered by Window A.

But it also looks back on the past results of itself.

If you buzz across Window A, depending on the speed at which Algorithm A can execute, it will pick up patchy past results.

To fix the only option I can see is to enforce algorithms with a self lookback to wait for past results to be ready before executing future results. This adds a new kind of complexity, and requires a few other moving parts to be present.

e.g. we need to #78 to be present, and we need to know what is currently being executed. That is all the information required to understand if the current triggering window needs to be stalled whilst old results come in.

[solvicode]

All the building blocks are there to now implement this fix:

1. we register and update the window status
2. we preallocate and update all algorithm results

Now, there just needs to be an intelligent mechanism to throttle window executions pending conditions such as whether required past results are still running.

This also feeds into a more intelligent rate limiting mechanism, where the processors specify their individual rate limits, and the core respects it. I will open an issue for this.

In any case, #109 should be implemented first. The code is getting messy trying to support data layers that wont come.

[solvicode]

Window and algorithm persistence is now implemented, but we're doing nothing with it.

In order to make this feature useful we need to do the following when emitting a window:
1.