refactor: move extending part to sqlparser

[Rachelint]

Description

Now, the method of extending sqlparser in ceresdb is too rough. We copy tons of codes from sqlparser and it's a kind of hard-fork in fact. So as I think, forking sqlparser and moving the extending part to it may be better.

Proposal

• Moving 'Statement' used in ceresdb to sqlparser.
• Add related keywords.
• Add related branch in parse_statement().

Additional context

[waynexia]

@dust1 @waynexia I intend to refactor as #155 temporarily.
But I think it's still no so good.
-- from #154 (comment)

Yep... The burden of maintaining the parser part still exists.

[Rachelint]

@dust1 @waynexia I intend to refactor as #155 temporarily.
But I think it's still no so good.
-- from #154 (comment)

Yep... The burden of maintaining the parser part still exists.

The functions(such as parse_columns, parse_optional_column_option, etc) are customized in ceresdb and conflicts with those in sqlparser. It seems not so suitable to move them to sqlparser.