Update evaluator to V2.0

[CarlosNZ]

I have re-built the expression evaluator from scratch for my own project, and it's a lot more powerful, well organised and designed, and it should be 99% backwards compatible (so existing expressions continue to work without re-configuring):

https://github.com/CarlosNZ/fig-tree-evaluator

At some stage it'd be good to move conforma over to use it, but that'll take a bit of time to refactor (though hopefully with no config changes), so only when we have time.

However, some of the features might be useful for handling the Medsafe data lookup and pre-filling the list builder. I'm not sure yet, so I'm just flagging this as a "Maybe" until I get further into it and decide if it's necessary. (Not necessary for now)

In particular, the features that might be helpful:

• additional operators: (split, multiplication)
• better error reporting
• evaluateFullObject option -- when creating "default" expressions for the listBuilder, it may be necessary to create a large response object that has evaluator expressions deep into the object tree, not just at the root level. We could make a really complicated "buildObject" expression, but it'd be simpler to use evaluateFullObject and just put the expressions in at the required leaves. We shall see...
• "Fragments" -- we can store common expressions in the global config, which should make creating complex expressions simpler for commonly re-used elements.
• simple caching -- so it won't make the same network requests over and over
• More: https://github.com/CarlosNZ/fig-tree-evaluator#changelog

Steps for migration

• Update server to use it
• Migration code to remove all {value: ...} objects from expressions (that's one of the few things not fully backwards compatible, as it's best left in the past)
• Write comprehensive GUI for expression building (In Progress)
• Update front-end to use
• Create some Fragments for back and front-end (see below)
• Testing

[CarlosNZ]

Not required for Medsafe, leave for longer-term upgrades

[CarlosNZ]

Speaking of Fragments -- let's start a list of common evaluator expressions that we should define as Fragments in the system (please edit this list):

• Name of System Regulatory Org
• Current user (or applicant) data (can take a parameter specifying field/path of desired property)
• alias to "responses" object (with parameter just the code/path of required response value)
• ...

[CarlosNZ]

alias to "responses" object (with parameter just the code/path of required response value)

One additional bonus of doing things like this is that we'll be able to standardise the expression syntax between the front and back-end. Currently there is some discrepancy in the paths to applicationData values, but we can hard-code this into the Fragment definitions (differently for each) and then we can use the same expression syntax for both in actual configs.