Fix Issue 22704 - Linker error when running the public unittests

[RazvanN7]

Documented unittests should not depend on symbols hidden behind version(StdUnittest) because:

• users will see exmples containing functions that do not appear in the documentation (for example: Ctrl-f ceqrel on https://dlang.org/phobos/std_complex.html)
• this may cause linker failures for template instances because the module where the documented unittests are extracted is compiled with -version(StdUnittest) whereas phobos is not.

The fix is to compile the module where the documented unittests are extracted without -version(StdUnittest). This makes sure that hidden symbols will not make it to the public user interface and also get rid of the linker errors.

cc @MoonlightSentinel @kinke

[dlang-bot]

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

Auto-close	Bugzilla	Severity	Description
✓	22704	blocker	Linker error when running the public unittests

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

• Regression or critical bug fixes should always target the stable branch. Learn more about rebasing to stable or the D release process.

To target stable perform these two steps:

1. Rebase your branch to upstream/stable:

git rebase --onto upstream/stable upstream/master

2. Change the base branch of your PR to stable

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 + phobos#8366"

[MoonlightSentinel]

Could those tests use isClose instead? Another option to consider would be exporting cequrel as the complex counterpart to the already available fequrel?

Shouldn't block this PR but those tests seem rather complex for public examples.

[MoonlightSentinel]

Rebased s.t. it uses the new Azure configuration (MODEL: 32omf)