feat: handle different placing of type names

[emilsivervik]

Hey,

First of all I just want to thank for all the awesome work on this library!

I've came across something that didn't work as expected a couple of months ago and created a fix for myself but now took the time to bring it here also. I'm sure there are some things left to do so I would appreciate some rubber-🦆

The issue is when trying to parse create a create statement

// Working
CREATE TABLE tb (id INT, KEY USING HASH (id))

// Not working
CREATE TABLE tb (id INT, KEY (id) USING HASH)

There was also an issue using order on the keys, such as this

CREATE TABLE tb (id INT, KEY USING HASH (id ASC))

which I'm not entirely sure how you'd like to handle, from my side I just did what was the appropriate solution (not using it) but I'd imagine from your end that would not be ideal solution.

EDIT: Documentation for create table statement

[iffyio]

Hi @emilsivervik Sure! Could you take a look at the CLUSTERED INDEX impl which has similar syntax and likely solution for parsing and representing the (id ASC) type scenarios? I'm thinking we'd probably be able to reuse that type, for example if we extend the IndexType parsing and representation to include:

pub enum IndexType {
    BTree(Option<Vec<ClusteredIndex>>),
    Hash(Option<Vec<ClusteredIndex>>),
}

And then something similar for the KEY support. Let me know if you have any questions.

Also, from the tests I'm assuming this is a mysql syntax? could you include a link to the docs maybe in the PR description where this syntax is described?

[coveralls]

Pull Request Test Coverage Report for Build 11294154244

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 44 of 45 (97.78%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.01%) to 89.325%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/parser/mod.rs	40	41	97.56%
<!--	Total:	44	45	97.78%	-->

Totals
Change from base Build 11263581007:	0.01%
Covered Lines:	30181
Relevant Lines:	33788

---

💛 - Coveralls

[iffyio]

Marking this as draft in the meantime as we're no longer waiting on a review. @emilsivervik please feel free to undraft and ping when you want us to take another look!