Use Rich more broadly?

Rich is neat. Do we want to leverage it more broadly?


Dask gets lots of love around our error messages. Good error messages reduce user pain. Rich might help us to improve our current error messages and user feedback. I suspect that once we start using it people might also really enjoy building more with it (it appears to be fun).

However, it would be a new dependency. Do we want to take it on for some of the subprojects like dask.dataframe or dask.distributed?

For context, I created a new conda environment with python installed, and then installed rich and got the following new dependencies

```
Package Version Build Channel Size
───────────────────────────────────────────────────────────────────────────────────
Install:
───────────────────────────────────────────────────────────────────────────────────

+ colorama 0.4.4 pyh9f0ad1d_0 conda-forge/noarch Cached
+ commonmark 0.9.1 py_0 conda-forge/noarch Cached
+ future 0.18.2 py39h2804cbe_3 conda-forge/osx-arm64 Cached
+ pygments 2.10.0 pyhd8ed1ab_0 conda-forge/noarch Cached
+ rich 10.12.0 py39h2804cbe_0 conda-forge/osx-arm64 347 KB
+ typing_extensions 3.10.0.2 pyha770c72_0 conda-forge/noarch 28 KB
```

So, two questions for the group:

1. Where would we use this?
2. How do we feel about the added dependency?