Support for std::expected (and alternatives)

[Ahajha]

First of all, I'd like to say that pybind11 is an amazing library, thanks to everyone involved!

At my workplace, we use tl::expected for most of our error handling (and eventually will move to std::expected). Right now, we have to sort of "manually" unwrap these into Python on the bindings side. We often end up with large swaths of code that look something like the following:

auto maybe_result = /* do some work */;
if (!maybe_result.has_value()) {
    throw py::value_error(maybe_result.error());
}
return maybe_result.value();

It would be convenient if pybind11 provided a native unwrapper for these. I've made a prototype here, but it's not quite PR ready, there are still some questions I have about implementation:

1. Does a one-way wrapper make sense? It might be a bit of an opinionated decision, but it feels like a strange decision to expose a binding on the C++ side that takes a std::expected.
2. On that note, perhaps it would even make sense to only provide a "consuming" conversion... but less settled on that one, I can certainly be swayed.
3. Exception types are an issue, as some error values might make sense as one exception, and others a different one. I was thinking of maybe providing a few levels of customization:
   a. Have a default (maybe std::runtime_error)
   b. Allow users to specialize what errors map to what exceptions, perhaps just add a template parameter.
   c. Allow users to provide custom conversion, for example if the error wraps multiple different kinds of errors
   Another idea is to just require that users register the return type as an exception type known to pybind11, (and maybe also explicitly allow std::string).
4. The PYBIND11_TYPE_CASTER macro requires a name - for now I'm just calling it "expected", but I'm not sold. First, I'm not even sure if it needs a name if it's a one-way wrapper. Second, it would need to include the names of the value and error type surely... just not sure how. std::variant uses Union[...], but I don't think this is really like that.
5. Not a huge issue, but my prototype is written with C++20 features, I presume those would need to be replaced.

Would love to hear some thoughts on this, thanks in advance!

[grarup]

To me it seems that you use std::expected it is to get away from exceptions, why should it not be the same for python code. My suggestion would be that std::expected simply becomes a python class with the same functions as it has in c++ you can then write a handler in python to convert to exceptions if this is the route you want to go.