Fix new DBML parser inconsistencies

[NQPhuc]

Summary

Resolve the following inconsistencies between old and new dbml parser behaviors:

1. Fix a bug causing multiple single quote to not report error.

Table user_role_in_diagram {
  role int [note: 'Role = sum(user's available permissions bit value)'] // should throw error on 's
}

2. Make keyworks check for default settings (true, false and null) case-insensitive.

3. Allow default value with double quote (v2 parser inconsistency with double-quoted list defaults #481)

4. Allow inline keywords in columns.

Table t {
  id int pk
}

5. Allow multiple column names on the same line in indexes definition.

Table citites {
  id integer pk
  name string

  indexes {
    id name 
  }
}

6. Allow array type in column.

Table users {
  id int
  order_ids int[]
}

• Improve error messages on validation errors
• Fix some errors reported with invalid error location (NaN on line and column)

Issue

(issue link here)

Lasting Changes (Technical)

• Ignore null attribute and setting bug cause by syntax error involve more than 2 single quotes
• Stop binding default indentifier to Enum
• Keywords check in binder and intepreter is now case-insensivity
• Update tests
• Refactor validator to not use the Template Method pattern
• Refactor Interpreter to make it modular

Checklist

Please check directly on the box once each of these are done

• Documentation (if necessary)
• Tests (integration test/unit test)
• Integration Tests Passed
• Code Review

[ghost]

3. Unsupported: Array column types — due to the ambiguity in the grammar that this would introduce.

Table country {
  id integer
  cities string[] // not work
  // equivalent: cities "string[]"
}

This has been supported. However, there's a pitfall:

Table country[note: 'abc'] {
  ...
}

country[note: 'abc'] would be treated as an array node, instead of separately as a name and a list, due to some ambiguity.
This can be avoided by adding a space between them.
It can indeed be solved completely but it would complicate the parser significantly. In my opinion, this error is unlikely to happen and we can yield more informative error messages for this pitfall so the user can be more aware? @NQPhuc

[NQPhuc]

@HuyDNA I'm aware that since both table definition and column definition used the same rule (element-declaration), supporting array type for column would affect table definition as well.

I think for now we can accept the new inconsistency cause to table setting. However, please help show a informative message to let the user know they need to leave empty space between table name and setting [].

In the long run, we should consider breaking element-declaration into different declaration types, because as of right now, this is not very flexible.

[ghost]

@NQPhuc All consistencies have been resolved. Plus the following benefits:

• Error messages are more informative
• Better error markings: Example, all duplicate settings are marked, instead of only the last; All circular refs are marked, instead of only the last, etc. -> Better debugging
• The Interpreter is refactored into modules instead of being monolithic, adding other elements is easier.
• The Validator is more flexible, allowing catching more precise errors.