Consider using pluggy for plugin management

[lemon24]

https://pluggy.readthedocs.io/

Pros:

• widely used (pytest, tox, datasette)
• standardization
• validation (all hooks have specs, argument names)
• opt-in arguments, deprecations (API evolution)
• discovery (via setuptools entry points)
• plugin management (plugin == named connection of hooks)
• some exception handling
• debugging support
• already documented

Cons:

• extra dependency
• widely used => harder to contribute to (Great care must taken when hacking on pluggy since multiple mature projects rely on it.)
• update-style hooks where we continue to run after failure may be fiddly to implement
• requests wrapper style hooks where the return value from a plugin is passed to the next plugin might be fiddly to implement
• LIFO order
• how would lazy plugin loading work?

[lemon24]

I had another look at pluggy, and confirm the pros still stand.

However, the following two cons remain:

• update-style hooks where we continue to run after failure may be fiddly to implement
• requests wrapper style hooks where the return value from a plugin is passed to the next plugin might be fiddly to implement

As far as I can see, the calling logic is buried deep within the codebase, so it likely can't be / isn't meant to be changed.

There's also https://github.com/pytest-dev/pluggy/issues/419 says collecting exceptions is out of scope, but it also mentioned further down that it may be solved in https://github.com/pytest-dev/pluggy/issues/321; it may be worth describing the reader usage patterns in that issue?