[Draft] Use dicts to write configs

[dwreeves]

Main changes:

• Add support for dicts to be passed into @rich_config(help_config=...).
  • The current behavior, which I think I'm going to keep (but need to document), is to merge the dict into the parent context's help config.
  • This still leaves a lot of questions unanswered about the config resolution but I am overall satisfied with this API decision, since the typical user won't notice a difference between merge and instantiating a new object, whereas users looking for more customization haven't had a nice way to access merging. And it just seems to make sense that it would do this behavior: you set a large RichHelpConfiguration() at the top, and each sub-command may have a tiny tweak. That makes sense!

Misc. changes:

• Make typing more "Rich". At the end of the day the command class's type is Type[RichCommand], and this typing is covariant, so it cannot ever return a super-type. The should can be safely updated to return that.
• Deprecate RichCommand.help_config. It didn't feel like this made sense back in 1.7, now it feels less like this makes sense, since rich help configs should be resolved in the context level (since they need to inherit from their parents).
• Add stacklevel=2s to the deprecation warnings.

[dwreeves]

I'm likely going to keep this open for a while. I want to get down a sensible and flexible system for resolving the config, aimed at:

1. Zero difference to the vast majority of users who just want pretty outputs without much effort.
2. Lots of convenience, sensibility, zero astonishment for users looking for lots of customization.

And I'd rather do too few changes and too few API guarantees than too many.

Also, see #134.

[dwreeves]

I think I am starting to settle on this configuration logic. I think it makes sense and is the least bad / least "astonishing" of all other alternatives. https://github.com/ewels/rich-click/issues/134#issuecomment-1872386532