add a client side axe implementation to quantify accessibility errors

[tonyfast]

this PR reintroduces widgets and mathjax. probably making more accessibility violations.

demo: https://iota-school.github.io/notebooks-for-all/branch/axe-authoring/exports/html/lorenz-executed-a11y.html

most of often axe is used in CI to guide accessibility. this pull request experiments with a client side use of axe to expose accessibility vulnerabilities to the assistive technology. the axe violations are contained in a dialog that exposes the results.

with this information on the page we can alert assistive technology users to errors that can expect, rather than be surprised by them.

further, this approach can benefit the authoring of accessible notebooks by providing real time linting on outputs. if our notebook substrate is accessible then we can only make it less accessible.

[tonyfast]

it seems this feature is weird after soliciting some feedback in the a11y slack. a valid concern are false positives/negatives from automated tests. the way it is implemented now is definitely wrong, but it was the cheapest way to demo.

while this feature might be weird in reading mode. there is probably a useful story for including axe tests while authoring notebooks. if an author is concerned about accessibility then they can optionally invoke axe audits.

personally, i think i would find a lot of value in the integrated authoring experience. this is something that could be provided as a jupyterlab extensions. folks can configure their axe tests with a GUI and they can be run against entire notebooks or incremental outputs.

[tonyfast]

this feature should made optional and disabled by default in python. it will be a hard-coded feature in the page. it will be useful in development modes.

[tonyfast]

gonna merge in a baseline configurable prototype of some client axe testing cause we think it could be valuable for authoring.