Added type hints to the Column class

[morozov]

Q	A
Type	improvement
BC Break	yes

[jwage]

Can we (should we?) separate the BC breaks due to adding type hints and BC breaks from us changing default behavior? IMO, while changing the defaults may be a good idea long term, I am not sure if making the change along side adding type hints is good. May be better to have 1 PR to add the type hints while maintaining behavior and then another PR to change the defaults. This way the defaults changing can be discussed in isolation from all the other changes and the type hints can probably be merged faster. If I am missing something, feel free to correct me. Just starting to get up to speed with the great work going on here.

[morozov]

@jwage I get the intent but if we want to take this route, the changes have to be implemented in the reverse order:

1. Drop the defaults (the real BC break)
2. Enforce strict argument types (a break only for API implementors, not consumers).

The existing defaults only make sense with non-enforced argument types (hence the is_numeric() checks). If we introduce the strict types first, it will implicitly break the behavior covered by is_numeric().

I like the idea of the split in general. Especially, given that there are still some leftovers of the default value of 10 in Comparator. I'll open a separate PR.

The feedback from Marco was addressed.