Run contracts on the returned object

[limepoutine]

Instead of a copy. Unsure if this is an optimization or a fix.

[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#22203"

[rikkimax]

On this note, it's approved if somebody would be willing to make contracts be called by the caller instead of the callee.
Would you like to have a go at it?

[limepoutine]

Does that mean hdrgen should also be able to generate contract bodies? Fixing hdrgen is much more daunting to me.

[rikkimax]

Right now only classes need contract bodies specified.

I don't know what the current state of it is.

But the .di generator has a lot of other problems like not being run after semantic analysis has completed.

[WalterBright]

Please provide an explanation of what is going on in this PR?

[limepoutine]

This sets fd.vresult.nrvo = true so that all generated contract delegates actually references the hidden pointer, instead of a copy of the returned object. Yes, this is very confusing and not production-ready.

Also this happens to be an optimization for foreach with opApply (no more copying to __result and then to the hidden pointer).

[thewilsonator]

Is this pR good to go?

[limepoutine]

This is technically ready, but I am trying to find a less hackish way to solve RVO madness. Will ping after a few days if this is the best thing I can do.