Clarify truthiness definitions in logical operators

[NullVoxPopuli]

Been doing some pondering as implementing

• RFC#562 - {{and}}, {{or}}, {{not}} as keywords ember.js#21337
• Adding Logical Operators to Templates #562

The RFC was originally written under an assumption that ember-truth-helpers used a JavaScript definition of truthiness, and wanted to use a handlebars definition of truthiness.

It's worth bringing this up again because:

• ember-truth-helpers implemented handlebars truthiness: https://github.com/jmurphyau/ember-truth-helpers/blob/463f748d39d245fbbb2f3555a78a01b31e607a92/src/utils/truth-convert.ts#L85 (and a TS-way to ensure things are narrowed)
• we are only implementing these helpers in strict mode, so we don't need to worry about overriding behavior, and can let existing implementations shadow

However, if and unless are still using handlebars truthiness, and their behavior is a good argument for keeping the RFC as is.

And, TS can and does represent handlebars semantics now https://github.com/jmurphyau/ember-truth-helpers/blob/master/type-tests/utils/truth-convert.test.ts

Other discussions from the past:

• previous discussion on changing all of truthiness: https://github.com/emberjs/rfcs/pull/861/changes
  • this RFC does not actually propose a migration plan
• "handlebars truthiness ... design mistake" [Feat]: logical keywords snewcomer/glimmer-vm#3 (comment)

Important

I think we should keep the RFC as-is, and keep handlebars truthiness semantics. Because we can't really have some utils be one kind of truthy and if/unless be another kind