Allow for Markdown formatting in table cells

[shammamah-zz]

Existing issues like #222, #383, and #248 can be resolved if we add Markdown to the table cells.

[shammamah-zz]

@alexcjohnson Just had a discussion with @Marc-Andre-Rivet and it appears that this will require some more discussion on the specifications:

1. How will custom/CSS styling behave?

• Right now, the height of the table rows is fixed, and if users start adding in, e.g., level-one headers in Markdown, it might lead to some visual problems.
• Markdown has default styling for headers, links, lists, etc.; do we allow for these to be overridden by users? AFAICT this isn't a typical way that Markdown is used (I think people use Markdown because it has the benefit of looking "clean" without having to come up with custom styles/CSS).

2. How will searching/filtering be implemented?

• If we're storing the cell contents as a plain text string that represents the markdown, and then only rendering the markdown, how do we ensure that search works the same way? (e.g., a cell with the text [Plotly](plot.ly) would just render as Plotly, but it's unclear if the rendered content (i.e., "Plotly") or the markdown string will be used when performing search/filter.
• There's also the question of how to handle cells with images in them.

3. We need to cache the results of processing the raw strings into the Markdown that will eventually be rendered.

[Marc-Andre-Rivet]

1. I think style / height might be mostly through documentation, like ellipsis / wrapping - same for default styling, making sure it's clear we don't do anything special.

2. Filtering / sorting on these cells probably won't make much sense. We could auto-disable it or let users do whatever they feel like.. whether it makes sense or not.. they are responsible for making a table that makes some amount of sense :)

3. The performance impact of md -> html will need to be measured, but yes, I'm pretty sure we'll want to cache those results. The conversion is costly.

[alexcjohnson]

1. For the most part I think markdown just constructs the indicated tags, and leaves styling those tags to the user. So I think @Marc-Andre-Rivet is right, leave that as is and document how you can modify it.

2. We've talked about potentially needing to operate on the content as displayed in the case of formatted numbers and string operators. I think eventually that may be a good idea here, and especially for simple use cases like links or bolding part of a string I can see users wanting filters like contains to work. Feels like we can start just using the raw string but perhaps later something to the effect of element.innerText, to eliminate non-displayed characters, would be better.

3. 👍 🐎