Fixed falsey/null value issues in jsong merge

[sdesai]

@michaelbpaulson

This fixes the falsey issues similar to the ones mentioned in Netflix/falcor#460 and #120 but this time for JSONG (issues in jsongMerge this time, last time it was in optimizePathSet).

[sdesai]

@michaelbpaulson, @jhusain

The message.type here seems to be a bug also, but 'fixing' it (I assume it's supposed to be message.$type as opposed to message.type) breaks the JSONG - Merge should write a simple path to the cache basic unit test in jsongMerge.spec.js. Needed some input on what the expected output should be for this test to determine if the test is broken, or there are potentially more bugs in the jsongMerge impl, which need to be teased out.

This is the failing test, if I change this line to be message.$type:

1) Router Unit Internals JSONG - Merge should write a simple path to the cache.:

      AssertionError: expected { Object (references, values) } to deeply equal { Object (values, references) }
      + expected - actual

             "path": [
               "there"
               "is"
             ]
      -      "value": "a value"
      +      "value": {
      +        "$type": "atom"
      +        "value": "a value"
      +      }
           }
         ]
       }

[ThePrimeagen]

@sdesai you are correct. I think the good news is that we remove that statement and only ever use the value that is handed to us. This could potentially strip some valuable meta data on a node by using the .value of the handed back value.

So what I am saying is that you were correct in assuming that this is incorrect, because it is. But the fix is to remove message.type ? message.value : message with message

[ThePrimeagen]

This is good to me.