Refactor SQL() methods

[apstndb]

This PR refactors SQL() methods.

• This PR only modifies ast/sql.go
• The correctness of the refactoring is ensured by not making any modifications to testdata.
• Some of the current implementation is incorrect, so they will be fixed in a separate PR.
  • Empty struct is better to be unparse as STRUCT(), but currently STRUCT<>(). discussed Refactor SQL() methods #173 (review)
  • ast.ChangeStreamForTable doesn't implement ast.Node
• It is a part of Refactor SQL(), Pos(), End() #151

Note:
There is a idea to introduce text/template style conditions.

https://pkg.go.dev/text/template#hdr-Actions

{{if pipeline}} T1 {{end}}
	If the value of the pipeline is empty, no output is generated;
	otherwise, T1 is executed. The empty values are false, 0, any
	nil pointer or interface value, and any array, slice, map, or
	string of length zero.
	Dot is unaffected.

It can simplify more, but empty slice, map handling may require to use reflect because empty slice/map are not the same with zero values, and their types doesn't satisfy comparable.

Added: I have implement only zero value as false, but it seems not useful than expected: 1606256

[makenowjust]

We intentionally distinct STRUCT and STRUCT<> because the first means a struct having any fields, and the second is the struct with no fields. For instance, select CAST(struct(1) AS STRUCT<x INT64>).x is valid, but select CAST(struct<>(1) AS STRUCT<x INT64>).x is invalid.

[apstndb]

Thank you for your explanation.
I understood your intention.

We intentionally distinct STRUCT and STRUCT<> because the first means a struct having any fields, and the second is the struct with no fields. For instance, select CAST(struct(1) AS STRUCT<x INT64>).x is valid, but select CAST(struct<>(1) AS STRUCT<x INT64>).x is invalid.

My thought is that:

• It is StructLiteral, not StructType, so there is no semantic difference between STRUCT<>() and STRUCT(). It can be normalized without ambiguity.
• STRUCT<>() is valid, but it can feel unfamiliar because it has no fields to name or type.
• The official docs describe only STRUCT().

It might be a good idea to comment that both STRUCT() and STRUCT<>() are lexically preserved.

[makenowjust]

Perhaps, we need to split the current StructLiteral into a new two s.t. TypedStructLiteral and TypelessStructLiteral for clarity.

[apstndb]

LGTM for splitting.

In ZetaSQL, both of them are treated in ASTStructConstructorWithKeyword, but they can't be mixed.

• In typed struct syntax

  AS alias is not allowed on the input expressions.

  STRUCT<x int64>(5 AS x)	Error - Typed syntax does not allow AS

Note:

• Splitting will be a part of Support typeless STRUCT syntax with field name #143

[apstndb]

Thought: The existing SQL() definitions don't use token.Pos.Invalid() without negation, so why is there no token.Pos.Valid()?