Have a way of registering a "supported" list of viz types

[xtinec]

Is your feature request related to a problem? Please describe.
There is a need to include experimental viz types like apache/superset@43ed9a6
Currently, we hardcord the viz types we want to register in various preset files in superset.

Describe the solution you'd like
It seems we need a config value in superset called SUPPORTED_VIZ_TYPES, which contains an array of keys of supported viz types (e.g. 'table', 'word_cloud', ...) and different instances of superset can choose to include or exclude experimental viz types like kelper. Available values for SUPPORTED_VIZ_TYPES will be populated by superset-ui using keys of plugins that are found undersuperset-ui and superset-ui-legacy

Describe alternatives you've considered
We could define one-off feature flags for kepler in superset but it doesn't seem right as the viz plugin themselves would be located in superset-ui or superset-ui-legacy.

Additional context
None.

@kristw @williaster @mistercrunch

[kristw]

I propose another solution.

• First of all, make kepler a plugin. This can be a standalone repo for single plugin npm package.
• Every organization defines their own preset as separate npm packages: e.g. superset-preset-chart-airbnb, superset-preset-chart-lyft. These presets can live in organization-specific repositories or even personal ones such as superset-preset-chart-kristw. Then in lyft preset you can include kepler plugin.
• Then in Superset, this is the part I haven't fully figured out yet, be able to point which preset to use. We can make script to add preset and make it npm install and update some config file that webpack reads from and substitute the default list of presets with the specified ones. The complex part is to ensure only uncustomized files are checked into the main repo and developer experience is not interrupted too much.

If this thing were to scale. The core Superset code should not know anything about vis types.