Refactor: Extract combine and extractLast from Expression AST node to semantic layer

[Adityazzzzz]

Following up on pr #22597 the architectural guidance from @ibuclaw. It focuses on migrating functions that perform actual semantic mutation on the AST.
Changes:

• expression.d: Removed the static AST-mutating member functions combine (all overloads) and extractLast from the Expression class.
• expressionsem.d: Relocated these as free-standing extern(D) functions.
• cxxfrontend.d: Added the appropriate D-to-C++ forwarders inside the extern (C++, "dmd") namespace to ensure GDC/LDC consumers can still access the exposed routines.
• Updated all internal call sites across the compiler (clone.d, dcast.d, optimize.d, etc.) to use the free functions.

This successfully decouples tree-building logic from the pure data node while maintaining full C++ interoperability. I'd appreciate any review on whether the cxxfrontend.d wrappers align with the expected GDC/LDC integration patterns!

[dlang-bot]

Thanks for your pull request and interest in making D better, @Adityazzzzz! 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#22618"

[ibuclaw]

No need for these, they were already extern(D) so the C++ clients aren't using them.

[Adityazzzzz]

@ibuclaw Since they were strictly extern(D) originally, the C++ clients were never hooking into them anyway. I've removed the wrappers from cxxfrontend.d,

I went ahead and removed the C++ wrappers from cxxfrontend.d as suggested, but it looks like it triggered massive failures across the CI pipeline (all the C++ interop and linker tests are failing). It seems the CI tests might actually be relying on those extern (D) forwarders indirectly!

Should I revert that specific commit to get the CI back to green, or is there a C++ header file somewhere else that I need to clean up?

[Adityazzzzz]

Thanks again for the guidance on the cxxfrontend.d wrappers, @ibuclaw Getting this pipeline right was my main goal before drafting my formal GSoC proposal.
Speaking of the proposal, I'm currently mapping out my 12-week timeline for the 5 main TODOs from the project description (dstruct.d, dtemplate.d, aggregate.d, dmodule.d, func.d).
As I plan my milestones, do you have a recommendation on which of these 5 is the most logical starting point for week 1? (For example, I noticed resolve inside dmodule.d looks like a heavy semantic pass that needs moving). I'd love to structure my proposal around the order that makes the most architectural sense to the core team