Add support for CSS-based theming on the canvas

[mattpap]

This PR:

• associates DOM hierarchy with canvas renderers (one element per renderer, including glyph renderers)
• allows visuals (fill, line, text, hatch) to consult CSS stylesheets for visual property values

An example showing CSS styling of plot background and axis background, ticks, labels and line (see examples/styling/visuals/css_variables.py):

Having an associated DOM hierarchy will aid debugging on the canvas, as well as set up ground work for accessibility/ARIA support and perhaps fully CSS-based layout in the future:

Performance implications of the DOM hierarchy should be negligible.

• fixes [FEATURE] Support using CSS Variables in place of colors #12759
• fixes [FEATURE] HTMLLabel to support stylesheets and css_classes  #13652
• fixes [BUG] DataTable inside Dialog #13787

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.62%. Comparing base (e61219b) to head (a53da8c).
Report is 21 commits behind head on branch-3.5.

❗ Current head a53da8c differs from pull request most recent head 55d9deb. Consider uploading reports for the commit 55d9deb to get more accurate results

Additional details and impacted files

@@              Coverage Diff               @@
##           branch-3.5   #13828      +/-   ##
==============================================
+ Coverage       91.57%   92.62%   +1.04%     
==============================================
  Files             326      326              
  Lines           20737    20767      +30     
==============================================
+ Hits            18990    19235     +245     
+ Misses           1747     1532     -215     

[mattpap]

This is tentatively ready for review. There is a class of failures (resulting in multiple integration test errors) that I'm fighting with, which a side effect of bad design around DOMView.render() and DOMView.after_render(), but fixing that is unrelated to any relevant changes in this PR.

[bryevdv]

Approved with some minor inline comments.

Some other general comments:

• it would be really helpful if you can provide an example of embedding in a page that makes use of or refers to CSS in the template, not defined using Bokeh APIs
• it would have been very helpful to reviewers if this PR had been split up. Any/all of these would have made sense as standalone PRs, would have been trivial to approve very quickly, and would have made this PR also much smaller and faster to review as well:
  • BokehJS util func deprecations/removals
  • paint/render rename
  • adding status-quo versions new visuals's APIs (get_line_color etc) to have a single place to insert CSS changes in this PR
  • render_group move and StyledElement refactor

Does the generated DOM hierarchy include the model names, so that those could be used as selectors in some way? A purely type based option is a bit limiting if users want to style different axes on different plots, say.

Lastly, I guess the specificity of e.g. bk-LinearAxis is unavoidable? It would be nice if somehow just bk-Axis could be used for any axis type, but I don't really see a path to that.

[mattpap]

Lastly, I guess the specificity of e.g. bk-LinearAxis is unavoidable? It would be nice if somehow just bk-Axis could be used for any axis type, but I don't really see a path to that.

That specificity is there by design, because those classes are added for ease of identification of DOM components and thus ease of debugging. They are not meant for user consumption and they really can't be used for styling, because shadow DOM would prevent users from attaching any global or global-ish styling using those classes (this is why we are migrating to using CSS variables).