meta: factory function inconsistencies

Related to #25220

There are quite a few inconsistencies among the factory functions:

• naming: sometimes the name doesn't really describe what it does.
  • createStatement instead of createExpressionStatement: what statement does it create?
  • createBinary: maybe binary number literal?
  • createParen: ParenthesizedExpression or ParenthesizedType?
  • createSpread: SpreadElement or SpreadAssignment?
  • createThrow: becomes ambiguous once the ThrowExpression proposal advances to stage 4
  • createDo: becomes ambiguous once the DoExpression proposal advances to stage 4
  • Should all of the factory function names match the name of the Node exactly? If so, should they be renamed while keeping a deprecated alias around for backwards compatibility (like #25348)?
• nullable parameters:
  • createTypeLiteral allows the members parameter to be undefined
  • createInterfaceDeclaration on the other hand requires an array as members parameter
• overload signatures to avoid creating invalid nodes:
  • createYield has overloads for that purpose
  • createImportClause or createExportDeclaration for example allow all parameters to be undefined, resulting in an invalid node
• optional parameters:
  • objectAssignmentInitializer in createShorthandPropertyAssignment is optional
  • typeArguments in createTypeReferenceNode is required although it's nullable
• decorators
  • e.g. createConstructor or createExportAssignment require a decorators parameter although it's an error to have decorators on those nodes
• modifiers
  • e.g. createExportAssignment requires a modifiers parameter although this node cannot have any modifiers (not even declare)