Improve MySQL option parsing in index definitions

[mvzink]

This PR improves the situation for defining indexes using CREATE INDEX, ALTER TABLE, and CREATE TABLE, by parsing more MySQL options after the column list. (It doesn't really affect key definitions written as options on column definitions.)

The main benefit is supporting MySQL's preferred syntax for USING { BTREE | HASH }, whic is to place it after the column list, instead of before:

-- before: SQL standard, used for example by Postgres
CREATE TABLE t (x INT, KEY idx_name USING BTREE (x));
-- after: preferred by MySQL
CREATE TABLE t (x INT, KEY idx_name (x) USING BTREE);

By "preferred", I mean that MySQL, accepts both forms, but (1) the documentation states the former is deprecated, and (2) if you run SHOW CREATE TABLE on a table with such an index, it will rewrite the USING to come after the column list.

This is accomplished by parsing index options generically after the column list, which currently includes COMMENT and USING. This means these locations will also benefit from future expansion of index option parsing, such as VISIBLE and WITH PARSER. The downside to this approach is that to continue to support the standard syntax which requires USING before the column list, there are now two places where USING could be stored in the AST (the distinct index_type field or in the index_options list). I think this is acceptable to enable broad support and good fidelity.

A secondary benefit is also supporting a subset of MySQL's ALTER options for CREATE INDEX: it accepts ALGORITHM and LOCK options after the index options.

A final, tertiary benefit is rationalizing the code organization by moving CreateIndex and CreateTable from dml.rs to ddl.rs.

[iffyio]

LGTM! Thanks @mvzink!
cc @alamb