sql: add parsing for interleaved & partitioning with CREATE TABLE AS

[danhhz]

CREATE TABLE a (b) INTERLEAVE IN PARENT ... AS ...
CREATE TABLE a (b) PARTITION BY ... AS ...

The interleave/partition clauses could also plausably go after the AS,
but I felt like this was more parallel to CREATE TABLE where they go
right after the column defs. (Plus there's all sorts of grammar
conflicts with putting it after the AS).

Implementation is blocked on #20940, but in the meantime, this will
return a friendly error message.

Also cleans up some unnecessary function parameters that I noticed were
being passed around.

For #20178

Release note: None

[cockroach-teamcity]

This change is 

[knz]

Code apparently OK but ... I don't like the direction.

Has this been thought through properly? CREATE TABLE AS was never meant to be a "serious" feature, because it does not allow one to specify the PK of the newly created table (nor any other constraint / index). Without the ability to specify the PK, I don't see how we can define PARTITION by or INTERLEAVE IN PARENT properly.

---

Reviewed 9 of 9 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

---

Comments from Reviewable

[jordanlewis]

#20940 tracks adding the ability to specify the PK of the new table.

[danhhz]

@knz Yeah merging this depends on us planning to add the ability to specify PK for CREATE TABLE AS, which is tracked in #20940. I'm not sure how controversial that is and I have no real opinion on it. If we decide we shouldn't add the ability to specify a PK when using CREATE TABLE AS, then I will happily close this PR unmerged.

[bdarnell]

CREATE TABLE AS was never meant to be a "serious" feature

FWIW, it's in the SQL standard. I've found it most useful in conjunction with temporary tables.

[knz]

I'll be fully OK with this PR once we change the statement to also support PK/index definitions (a change which I also support). I wasn't aware of the separate issue, thanks Jordan for the link.

[danhhz]

Well I don't think that's happening soon. I was trying to return a better error than a syntax error, but I don't really care that much, so closing this.