feat: allow arbitrary command classes

[jayceslesar]

Add a new option :command_class that allows a user to specify a custom type for a command class, which will then attempted to be imported. Defaults to click.BaseCommand.

Closes #80

[jayceslesar]

Ah there is more too this because https://github.com/mkdocs/mkdocs-click/blob/master/mkdocs_click/_docs.py#L104 looks like a decent amount of those. Do we want to support a special option for each one of those checks?

[jayceslesar]

yeah would need to specify options for the following:

1. command_class (already implemented in existing commits)
2. multicommand_class https://github.com/mkdocs/mkdocs-click/blob/master/mkdocs_click/_docs.py#L104
3. option_class https://github.com/mkdocs/mkdocs-click/blob/master/mkdocs_click/_docs.py#L219
4. choice_class https://github.com/mkdocs/mkdocs-click/blob/master/mkdocs_click/_docs.py#L268
5. datetime_class https://github.com/mkdocs/mkdocs-click/blob/master/mkdocs_click/_docs.py#L274
6. intrange_class https://github.com/mkdocs/mkdocs-click/blob/master/mkdocs_click/_docs.py#L280
7. floatrange_class https://github.com/mkdocs/mkdocs-click/blob/master/mkdocs_click/_docs.py#L280

Seems feasible to just default to all the click ones as a default and use the same pattern that is added so far for command_class ?

[ofek]

After looking closer into https://github.com/python-trio/asyncclick, I'm hesitant to document the feature but I think it's okay if you add options for each of those as long as they are prefixed by something (and again, undocumented). I think that library is fundamentally wrong for literally forking the code rather than wrapping (in which case click objects would work because of subclassing).

I would appreciate feedback from @oprypin as I really think that library got it wrong.