Consider a fallback mechanisms when rich output can't be rendered

[joelostblom]

There might be occasions where the colored output from rich cannot be rendered (although we're currently only using the most widely supported markup styles from rich). There might also be occasions where our exception hooks are not properly overriding the default ones (but we are now covering both the regular python and the IPython interpreter).

We might want to try to account for this by providing some sort of fallback mechanism. Some of the possible routes we could take:

1. Wrap all rich output in some printable character like ` (backtick).
   • Pros: Easy to implement
   • Cons:
     • Visible also when rich is working which could appeared cluttered and redundant.
     • When rich is not working, the markup characters are still printed as is, e.g. [u], so wrapping these in another delimiting character might make the output harder to understand/more cluttered. We could potentially use the markdown module in rich to avoid this at the expense of losing different colors in the output.
2. Autodetect if rich is working and swap the rich markup with regular printable characters if it is not.
   • Pros: Only used when needed and avoids making the output marked up twice.
   • Cons: Likely hard to implement.
3. Manual flag to turn off rich.
   • Pros: Quite easy to implement
   • Cons:
     • Likely hard to discover
     • Maybe hard to control from software outside check-datapackage
4. Deal with exceptions as they come up, either by ensuring rich works there or implementing a case by case fallback mechanism.
   • Pros:
     • Avoiding implementing functionality for cases the might never occur (e.g. we might already cover all our bases for 99.9999% of envs where explain is used).
     • Can implement proper support instead of fallback mechanism (e.g. as in fix: 🐛 no traceback and correct rich formatting in IPython #249)
   • Cons:
     • Some users might be confused if they encounter the unrendered rich markup characters.