Fix #20985 - runnable\exe1.c heisenbugs on Win64

[dkorpel]

I narrowed it down to void initialization in this module. There's padding gaps in struct Relocation which don't get filled, and then the whole rel variable gets written out, including uninitialized bytes, which is suspicious. But just removing the rel = void was not sufficient, so I still need to narrow it down a bit further. Bisecting this was quite hard, since you have to build dmd with LDC -O3, and then run the runnable/exe1.c test 100 times before you can say it's not there anymore, which is a slow process. This current patch removing 7 void initializations has run succesfully 650 times.

[dlang-bot]

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

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

• In preparation for migrating from Bugzilla to GitHub Issues, the issue reference syntax has changed. Please add the word "Bugzilla" to issue references. For example, Fix Bugzilla Issue 12345 or Fix Bugzilla 12345.(Reminder: the edit needs to be done in the Git commit message, not the GitHub pull request.)

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#21099"

[dkorpel]

The rabbit hole deepens, because now bootstrap (dmd 2.079) sometimes fails. Apparently the mscoff code is masking an uninitialized read somewhere deeper in code generation. My new prime suspect is dmd.backend.cod1.loaddata, which tripped an assert once, and which could explain the difference in stack frame sizes seen in the diff: #20985 (comment)