Adding tests for LWG-4025

[ComixHe]

Implements LWG-4025 by omitting operator=(move_assign_base&&) for expected<void, E> when E is not movable, letting the defaulted move assignment fall back to copy.

This produces identical trait results to a conforming C++23 implementation, but is a structural deviation: the operator exists (dispatching to copy) where the standard excludes it, detectable only via custom SFINAE.

The alternative (SFINAE-constraining the operator) would break triviality (LWG-4026) for the common case. Would this approach be acceptable?

[X1aomu]

I have some good news: we can actually achieve both—implementing LWG-4026 without breaking the custom SFINAE scenario you mentioned.
And perhaps even better news: the current implementation already satisfies these conditions without requiring any modifications. 🤣

To verify this, we can simply keep the test additions (though the custom-SFINAE test case will need a minor adjustment). There is no need to modify the implementation itself; running the tests directly will confirm this. :)

I appreciate the tests you've provided. Although the core implementation doesn't need to be updated, these test cases remain valuable for future regression testing, and I would very much like to keep them in the repository.

As a supplementary note regarding my understanding of LWG-4025: the reason the standard's resolution only targets expected<void, E> is that only the void specification had an issue. In zeus::expected, our implementation actually already satisfies the logical requirements of LWG-4025. Because we are targeting C++17 and cannot rely on C++20 concepts, we had to use an alternative implementation technique that applies uniformly to both expected<T, E> and expected<void, E>. Therefore, if we ever needed to make explicit code changes based on the LWG-4025 resolution, we couldn't just blindly patch expected<void, E> to match the standard's wording. We would need to make broader, symmetrical changes across both variants to maintain our internal consistency.

With this symmetry in mind, it would be even better if the test cases could be expanded to cover both expected<void, E> and expected<T, E>.

Thanks again for the contribution and the constructive discussion.

[X1aomu]

I‘d like to keep only the tests. And it would be better (not required) if tests could cover expected<T, E>.

[ComixHe]

Thanks for the thorough review and the clarification. I cross-checked the standard and confirmed the existing implementation is correct.

Updated the PR accordingly — reverted the code change, added the standard rationale in README, and expanded tests to cover expected<T, E> as suggested.

[X1aomu]

Thanks for the updates! The README is a bit verbose here. Maybe we can just put those details in the tests.