fix: Preserve the order of a context

[saig0]

Description

Fix an issue that did not store the context entries in the same order as defined in the literal (i.e. {a: 1, b: 2} is stored as {b: 2, a: 1}). The issue could be observed by using the get entries() function.

The root cause was not in the context functions but in how the context is created in the engine via EvalContext. Fixing the behavior by using a sorted map for storing the context entries and by avoiding the nesting of the VariableProviders.

As a result, the code of the EvalContext is a bit more complex but easier to debug. All variables and functions are stored in one provider instead of a chain with one provider per variable/function.

Related issues

closes #161 based on a previous try #340

[saig0]

@remcowesterhoud great catch. :+1:

I fixed the issue by using a SeqMap. :laughing: Additionally, I added a few more test cases with non-alphabetic order. :see_no_evil:

Please have a look. :eyes:

[remcowesterhoud]

bors merge

[github-actions[bot]]

Backport failed for 1.15, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally.

git fetch origin 1.15
git worktree add -d .worktree/backport-653-to-1.15 origin/1.15
cd .worktree/backport-653-to-1.15
git checkout -b backport-653-to-1.15
ancref=$(git merge-base a9f091d22b2939d445935fc6bcb8567a11e3e8ea efcaee50d09f7aad8f3e13318020ba2121aab445)
git cherry-pick -x $ancref..efcaee50d09f7aad8f3e13318020ba2121aab445

[github-actions[bot]]

Successfully created backport PR for 1.16:

• 659