util::Result design notes

The main goal for the util::Result class is to provide a standard way for functions to report error and warnings strings. The interface tries to make it easy to provide detailed error feedback to end users, without cluttering code or making it harder to return other result information. There have been multiple iterations of the design using different internal representations and providing different capabilities:

	Representation (approximate)	Notes
1	tuple<T,optional<bilingual_str>>	Original #25218 implementation in da98fd2efc1a6b9c6e876cf3e227a8c2e9a10827. Good capabilities, but larger type size. Supports error standardized error reporting and customized error handling with failure values.
2	variant<T,bilingual_str>	Final #25218 implementation in 7a45c33d1f8a758850cf8e7bd6ad508939ba5c0d. No support for returning failure values so not useful in many cases.
3	variant<monostate,T,F>	Pending #25601 implementation that allows choosing whether to use standardized error reporting or return custom failure values, but doesn't support having both at the same time, like approaches (1), (4), (5), (6) do.
4	tuple<variant<T,F>,bilingual_str>	Original #25608 implementation in c29d3008de9314dd463ed08e8bff39fe55324498. Basically the same as (1) except it uses separate success and failure types instead of the same type. Using separate success and failure types makes the result class a little less flexible but can help avoid some ambiguity and inconsistent result states.
5	tuple<T,optional<bilingual_str>>	Final #25608 implementation in dd91f294206ac87b213d23bb76656a0a5f0f4781. Essentially the same as original implementation (1) except has some usability improvements.
6	tuple<T,unique_ptr<tuple<F,bilingual_str>>	Pending #25665 implementation. Supports returning failure values, uses separate success and failure types to avoid ambiguity, uses unique_ptr to reduce result type size, and avoids heap allocation in the happy path.

Prior discussions & history

• furszy introduced a BResult class providing a standard error reporting mechanism in #25218. It was renamed to util::Result in #25721 but kept the same representation and capabilities.

• MarcoFalke suggested using BResult for the LoadChainstate function in #25308 (comment). Inability to use BResult there due to lack of support for failure values led to initial work on #25608.

• w0xlt wrote a StructuredResult class in #25308 adding the ability to return failure values but sacrificing standard error reporting, which led to more work on #25608.

• martinus suggested a space optimization in #25608 (comment) that also made it easier to support distinct failure & success types, leading to #25665 as a replacement for #25608.