Treemap trace

I believe treemaps could deserve to be supported natively as a new type instead of having to precompute the rectangles and add them as shapes.
One reason is that using shapes prevents us from directly using a colorscale on another trace attribute (since the shapes' fillcolor attribute only accepts a color value).

[rodrigomurta]

It would be nice to have support to R too. Now treemaps are restricted to Python and Matlab.

[jackparmer]

(Related: #2221)

[nicolaskruchten]

There are three possible visual forms that are in principle treemap-like, but whose intent and natural input format differ:

1. Hierarchical part-of-whole represented as nested rectangles, with various algorithmic approaches, like optimizing for square aspect, or slice-and-dice etc
2. 2-level x/y Marimekko plots which are arguably more bar-like than anything else, as they can be made with and benefit from continuous/cartesian axes e.g. https://datavizcatalogue.com/methods/marimekko_chart.html
3. Multilevel mosaic plots (more than 2 levels) whose input data more closely resembles the parcoords one (see https://www.perceptualedge.com/articles/visual_business_intelligence/are_mosaic_plots_worthwhile.pdf for commentary)

Let's focus strictly on number 1 in this case, assuming that this is a trace-with-its-own-domain like sunburst and that it does not have cartesian axes.

Within that, there are a bunch of dimensions to explore, requirements-wise (these may overlap a lot, naturally):

1. Color: there are many charts in the wild, especially financial ones, that use continuous color on treemaps (e.g. https://finviz.com/map.ashx)
2. 'headers' for the rectangles that show the names of the containing ones. Note: this messes with the strict area calculations a little bit! (e.g. https://finviz.com/map.ashx) ... some implementations put the containing header in the top-left and the contained name in the bottom-right for example http://bl.ocks.org/ganeshv/6a8e9ada3ab7f2d88022
3. Independently of headers, we might want to allow nesting borders or padding around the boxes and that messes with the math a bit also in terms of layout. I don't think we should do the "cushion gradient" effect that some implementations use. Here's an example of 'padding' https://observablehq.com/@d3/nested-treemap
4. Mouseover behaviour to show hierarchy (i.e. adding borders to all containing rectangles on hover)
5. Click to zoom in... double-click to zoom out? If there are 'headers' then you could click on the header to zoom out, similar to the way you click on the center of the sunburst to zoom out
6. tweening when zooming in and out, keeping in mind that the aspect ratio will change while zooming
7. text/hover info/templates, to show the percentage of whole, percentage of parent, name etc
8. a top-level "path" bar that summarizes the current location within the treemap and allows zoom-out (e.g. http://bl.ocks.org/ganeshv/6a8e9ada3ab7f2d88022)
9. The ability to constrain the number of visible levels like we do in Sunbursts (e.g. http://bl.ocks.org/ganeshv/6a8e9ada3ab7f2d88022 again)

There's lots of d3 prior art here... https://www.d3indepth.com/layouts/

Other implementations:

• Highcharts: https://www.highcharts.com/demo/treemap-large-dataset