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.

[limepoutine]

Oh yeah I dodged a bullet. Without #22189 this could corrupt the stack when __result is inlined with NRVO.

@thewilsonator This is ready to go.

@rikkimax I just realized caller-inserted contracts and #22078 require some fundamentally identical facilities to track the type (ref-ness included) from every possible source of value. This allows DMD to (a) generate appropriate contract calls for each branch without resorting to the base type, (b) replicate addressElem() in the frontend and continue to pretend contracts run in callee's stack frame, (c) get rid of #22078, and (d) replace the remaining compiler-generated blits with precise copy/move semantics (most infamously, __tmpfordtor, which isn't really needed when moving true rvalues).

Maybe I'm the only one who writes (hyp ? hyperbola : ellipse).setEccentricity(1.0) and still expect it to throw, and point (a) may be dropped. Nevertheless, this in effect creates a temporary union type system in D, which enables an expression to have types like A | (ref A) as long as component types eventually unify. I'm unsure what would be a good implementation, be it adopting C++ gl/x/prvalues, creating a specialized visitor, or more messing with the type system?