Improve handling of charset and collate in column options.

[nicktobey]

dolthub/vitess#293 should be merged before this.

This PR does two main things:

Parse and validate the collate option, even on binary columns.

Currently the collate option is ignored on columns of binary type, an we just assume binary collation because it's the only one allowed. This is usually correct but causes some problems.

CREATE TABLE t (pk varbinary(10) collate utf8mb4_0900_bin); shouldn't parse, because it's attempting to use an illege collation for column pk. However, we currently ignore the option and parse it anyway.

CREATE TABLE t (pk varbinary(10)) collate utf8mb4_0900_bin; on the other hand, needs to succeed. Binary columns do not inherit the default collation of the table.

Reject the charset option except on columns that allow it.

According to MySQL, only text, sets, and enums are allowed to have character sets. Attempting to specify a character set for any other column type is an error. Before this PR, we were simply ignoring the character set where it didn't make sense.

A good way to think of it is that varbinary is like a shorthand for varchar charset binary. In fact, you're even allowed to write CREATE TABLE t (pk varchar(10) collate binary); and MySQL will generate a varbinary(10) column. Since the column already has a specified char set, it doesn't default to the table charset/collation. And you can't supply an explicit charset to the column because it already has one implicitly.

[max-hoffman]

The correctness fixes sound good, i like the organizational improvements, tests look good. @Hydrocharged might be able to comment on any collation/charset specific details that he understand's a lot better

[Hydrocharged]

LGTM as well!