Editorial: Reinstate "evaluating-async" state alongside AsyncEvaluating -> AsyncEvaluation

[guybedford]

This is in response to #171 by @kmiller68 where the usage of the ~evaluated~ state to indicate modules that are still currently async evaluating could be seen to be a confusing state definition. In addition, addressing a possible confusion that the [[AsyncEvaluating]] state has also been misunderstood before since it applies to both queued executions and running executions.

This is an editorial change which brings back the ~async-evaluating~ [[Status]] value which is set for any module either currently asynchronously executing, or waiting on a dependency that is currently asynchronously executing and also renaming [[AsyncEvaluating]] to [[QueuedEvaluation]] with a slight adjustment to completion handling where instead of treating execution completion as the transition of AsyncEvaluating to false as before, we then treat execution completion as the transition of the async-evaluating state to evaluated.

The previous issue with the ~async-evaluating~ status was that we still needed a separate field for AsyncEvaluating due to handling cycle transitions, as discussed in #114. The QueuedEvaluation field then still provides three purposes: iindicates which modules have async dependencies, it acts as the counter for async execution ordering and it handles within-cycle async queue attachment.

This PR can be seen as performing the following (non-normative) editorial replacement operations in order:

• Replace all ~evaluated~ state checks with a check for ~evaluated~ or ~evaluating-async~.
• Replace the ~evaluating~ -> ~evaluated~ transition for async executions with an ~evaluating~ -> ~evaluating-async~ transition.
• Rename [[AsyncEvaluating]] to [[AsyncEvaluation]].
• Append a transition of [[Status]] from evaluating-async -> evaluating at all sites where we previously set [[AsyncEvaluating]] to false.
• Never transition [[AsyncEvaluation]] back to false, and instead entirely use the [[State]] == ~evaluated~ transitions for these checks.

This is editorial since the [[Status]] is currently entirely private to the module execution semantics, so this editorial change is more about understandability and ensuring the underlying state model is as clear as possible for future module system additions.

[codehag]

This looks good now.

[Ms2ger]

I haven't done a super-thorough review, but the general idea seems to make sense. I'm happy to merge.

[codehag]

we're doin' it. MERRRGE