Fix evaluateExpression for proper handling of literals VS instance names

[AntoineGautier]

Currently, we have the following properties in templates.json:

      "value": {
        "operator": "none",  // unnecessary wrapping of bare Boolean
        "operands": [
          true  
        ]
      },
// ...
      "enable": "have_chiWat"  // client-side value resolution fails

While literal strings – which are stored quoted in modelica-json "\"String literal\"" – are stored unquoted "String literal" in templates.json.

The logic is backwards.

• In the first case we should simply store "value": true since we have a bare Boolean, so really no need for the expression wrapper with "operator": "none".

• In the second case, there is now way on the client side to distinguish between literal strings and instance names. If anywhere, the expression wrapper with "operator": "none" should be used here, for the client to resolve.
  Another option would be to store literal strings quoted in templates.json – this is how modelica-json encodes them.

Side Issue – Invalid String Comparison

With string-type variables such as parameter String str = "AAA", the client would fail evaluating the following equation str == "AAA". The function resolveToValue is called on each operand and returns null if the instance lookup fails. So the equation becomes "AAA" === null after lookup, which evaluates to false.
Enumeration-type comparison succeeds though because of isModelicaPath early return inside resolveToValue.
So the following equation is properly handled by the client.

              {
                "operator": "==",
                "operands": [
                  "secOutRel.typSecRel", // resolveToValue returns the actual variable value
                  "Buildings.Templates.AirHandlersFans.Types.ReliefReturnSection.ReturnFan" // resolveToValue returns it as-is because `isModelicaPath` returns true
                ]
              },

Explicit Tech Debt

The side issue with literal strings is explicitly stated at https://github.com/lbl-srg/ctrl-flow-dev/blob/main/docs/tech-debt.md?plain=1#L23