Do proper construction when initializing __result

[limepoutine]

Calling copy constructor is currently done through the side effect of constructing a temporary variable. It's equivalent to constructing __result directly without jumping through another temporary, so this PR changes returning through __result to construct it instead of making a temporary. This removes a special case in the backend.

This PR is also in high-risk territory because it affects all functions using out contract or opApply. What's worse, this PR is not easily testable because copy/move-return should behave exactly the same as copy/move-initialization.

cc @ibuclaw @kinke

This should fix GDC's bug w.r.t out contract breaking RVO in move-return. Should be fine with LDC at a first glance, but warrants a look.

[dlang-bot]

Thanks for your pull request and interest in making D better, @limepoutine! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#22620"

[ibuclaw]

@limepoutine seems reasonable. The __result variable should only ever be assigned to once in a function.