Parsing support for if expressions. (#2883)

We model `if a then b else` as a prefix operator for parsing precedence purposes. The rule that a statement starting with `if` is never an `if` expression is handled implicitly because the statement parser never invokes the expression parser for a statement starting with `if`.

This exposed a bug in our diagnosis of the whitespace rule for prefix operators, which was incorrectly being applied to non-symbolic operators in some cases, and was producing a bogus second diagnostic in some cases, which is also fixed here.

toolchain/parser/parse_node_kind.def

@@ -173,7 +173,7 @@ CARBON_PARSE_NODE_KIND_BRACKET(ForIn, VariableIntroducer)
 CARBON_PARSE_NODE_KIND_BRACKET(ForHeader, ForHeaderStart)
 CARBON_PARSE_NODE_KIND_CHILD_COUNT(ForStatement, 2)
 
-// `if` + `else`:
+// `if` statement + `else`:
 //     IfConditionStart
 //     _external_: expression
 //   IfCondition
@@ -259,6 +259,17 @@ CARBON_PARSE_NODE_KIND_CHILD_COUNT(InfixOperator, 2)
 // PostfixOperator
 CARBON_PARSE_NODE_KIND_CHILD_COUNT(PostfixOperator, 1)
 
+// `if` expression + `then` + `else`:
+//   _external_: expression
+//   IfExpressionThen
+//   _external_: expression
+//   IfExpressionElse
+//   _external_: expression
+// IfExpression
+CARBON_PARSE_NODE_KIND_CHILD_COUNT(IfExpression, 5)
+CARBON_PARSE_NODE_KIND_CHILD_COUNT(IfExpressionThen, 0)
+CARBON_PARSE_NODE_KIND_CHILD_COUNT(IfExpressionElse, 0)
+
 // Struct literals, such as `{.a = 0}`:
 //   StructLiteralOrStructTypeLiteralStart
 //       _external_: DesignatedName