RFC#562 - {{and}}, {{or}}, {{not}} as keywords

[NullVoxPopuli]

Implement and/or/not.

RFC Link: https://rfcs.emberjs.com/id/0562-add-logical-operators/

We do need to also PR an update to the RFC to say that these are only available in strict mode

We decided that new helpers would only be available in strict mode, because we don't want to change loose mode, for safety reasons

[mansona]

I feel liks since this will be going in the API docs we need to have some sort of cross-link to some document that explains what Handlebars truthiness actually means 😂 I can see in the implementation that we're using the toBool() function, does that have public API docs?

[mansona]

The code looks fine to me (with my limited experience reviewing lanugage-level PRs like this) but I did notice that we are exposing sometihng in the API docs that is under-explained 🤔 I have approved this to not block the implementation but I would like to see the API docs improved before this makes its way to beta (i.e. you can do a follow up PR if you like but I would like you to commit to it 👍 )

[NullVoxPopuli]

Converted back to draft because:

• I want to explore what making argument evaluation lazy would look like (I know how, I just don't know how much work it is yet)
• I want to ask the community if we should change the truthiness semantics to be more js-like, since the original RFC was for loosemode without keyword shadowing, and now we are only going to support this in strict mode which has keyword shadowing

[void-mAlex]

the one thing I would hate from going to js thruthy semantics is empty arrays being truthy

[NullVoxPopuli]

that's how ember-truth-helpers currently works, but I think since we have keyword shadowing, we/I should RFC an update that amends this RFC for and/or/not to say JS semantics for truthiness... because... [] being falsey is bonkers haha

hopefully I can get that submitted before the RFC meeting