Allow global expressions to be reordered

[brynpickering]

What can be improved?

If users define their own global expressions then they get appended to the set of global expressions. If they then reference those new global expressions in an existing global expression, the ordering means the existing global expression won't understand the reference. This cropped up in #727 and could be solved by allowing an optional "order" or "zorder" attribute to be defined. This is usually defined as e.g. -1 to elevate a global expression to the start of the running order. Or users could be requested to list the global expressions in the config in the order they want them to be defined.

Version

v0.7.0dev6

[irm-codebase]

@brynpickering how is this a problem with the new math approach?
I thought it would go away since this type of reference is defined and then prepared during build...

For what I understand in the backend, having 'nested' global expressions should trigger nested execution during build, no?

If not, we could follow a similar approach to to how nested use is handled in the 'rich' YAML template definitions: solving them recursively while keeping a cache to catch 'cyclic' or ambiguous cases.