Allow to pass custom table components

[vbartusevicius]

Currently there is no way to change built-in table components. This PR enables some customization.
This is a bit different that customizing with custom Material theme as this allows to react to given props.

In example: you can change the color of Chip in TableFilterList depending on current value. Useful for filtering by some status-like fields - you will have one Chip indicating status with visual feedback in filter list instead of duplicating this feedback throughout entire table.

[coveralls]

Coverage increased (+1.06%) to 77.497% when pulling b06a025 on vbartusevicius:customizable-components into 4f83609 on gregnb:master.

[vbartusevicius]

@gregnb, @gabrielliwerant - could you take alook at this?

[gabrielliwerant]

@vbartusevicius There is a rather long backlog of PRs and issues, and they should be taken somewhat in order, unless it's a quick bug fix or something. This doesn't qualify, and so I'm afraid it may be a while. Additionally, I'm not too sure about this approach. The way customization tends to be handled now is through custom renderers. There's no precedent in the library for customization that works in the way you propose, so I'm not too sure about adding it.

[vbartusevicius]

@gabrielliwerant, yes there is a long backlog, but I don't see too much of activity there. I think this PR could help with cases like #351 In addition to that I intentionally introduced separate prop components as I think it brings more separation between purposes of props - now there is a bit of a mess: handlers, customComponents, options, configurations, etc. in one options prop.

If you think that it would be more reasonable to move components to individual options.custom* - I'm fine with that.

[patorjk]

This is an exceptionally cool idea. Currently much of what's described here can be done with the table's various customRender functions, however, this type of API (to me at least) is much easier to understand. This approach would also solve the Tooltip component problem described in #1217 (though this PR doesn't have Tooltip available as an override so I may look into that). It also lends itself well to the new plug-in selection, and would allow alternative forms of various components for common use cases.

The downsides I see are that if any prop name to one of these overridable components changes, the custom component will break. But these names have been pretty stable, and maybe saving such a change for a major release would be the way to go if such a situation arose. There could also be issues if any data formats changed, but customRender functions have this same issue. I may add something in the documentation about recommending the use of ~versions for apps that do lots of custom internal overrides.

Anyway, I've merged this into the upcoming v3 branch. Sorry for the delay and thank you for putting this together!

[vbartusevicius]

@patorjk - thanks for appreciation!