Redmine/6119

The user shouldn't have to think about it at all, but as can seen from the bugs in Redmine, they bump into cf_null all the time, and cf_null always comes from the guts of the code, not from their policy. So, the problem is, the user is very much exposed to CFEngine's internal usage of cf_null as a marker for "defined, but empty value". And btw, CFEngine has never forbidden cf_null to be used as the name for a bundle, or the value of a string. So this is completely bonkers, IMNSHO.

So, the core of the problem here is not that users put "cf_null" into their policy code. The problem is that internal functions pump cf_null into lists when they are about to return an empty list, because our evaluator is assuming that rval.item is not a null pointer, and that rval.item being a null pointer is an error for some reason. The test just simulates this condition, so fixing the parser to prevent cf_null from being explicitly used solves nothing. However, some people might have started to use cf_null to mark defined, but empty variables, and what one could have done in the parser is to simply allow to declare a variable without value:
```
vars:
  "empty_variable";
```

done. If internally we represent that as `(Rval){NULL, RVAL_TYPE_SCALAR}`, or `(Rval){"cf_null", RVAL_TYPE_SCALAR}`, or `(Rval){NULL, RVAL_TYPE_NOTYPE}` is entirely up to us, but only two of those options are cheap. The option chosen is not one of those two, sadly.

Taking values out of a linked list is neither fragile nor expensive. Constantly strcmp'ing list entries against CF_NULL_VALUE is both (because it's not as "constantly" as it has to be).