Run DMD's testsuite on Buildkite

[wilzbach]

Similar to #287

[dlang-bot]

Thanks for your pull request, @wilzbach!

[wilzbach]

dmd build failures are due to the test suite requiring gdb 8 :/
Not sure whether we can fix the testsuite or it's easier to install a newer gdb instance on all agents.
And probably the druntime timeouts are the same as we see on SemaphoreCI.

[wilzbach]

As this seems more complicated I splitted off the druntime test build into a separate PR: #301

[wilzbach]

Not sure whether we can fix the testsuite or it's easier to install a newer gdb instance on all agents.

Alternatively, we could skip the gdb tests for now.

[wilzbach]

This is still blocked on test_results/runnable/gdb14330_0.gdb requiring gdb 8.

[MartinNowak]

I'm not entirely on board with the direction this takes.

• Integrating into a single CI is nice
• Moving to a managed CI service is nice.

• This and other moves significantly increase the compute requirements, if that's the path we're taking, we should get the D Language Foundation onboard for the server costs.
• Please talk to @braddr, he and some other people are doing an amazing job of running 17 machines with various OSes for us (https://auto-tester.puremagic.com/hosts/). We should get him on-board. Also the auto-tester is still using an O(N²/2) retest scheme for passing PRs, so that's quite a lot of compute capacity. Running a buildkite-agent isn't much different from running the at-client loop, and in fact there would be some benefits (easy OS updates) to run the agents in a VM.
• Meshing all different tests into a single Buildkite pipeline has the potential to be confusing, It would be better to clearly split different test-suites into sub-pipelines (e.g. test-suite, bootstrapping, dub-projects) (Trigger Step | Buildkite Documentation).
• Let's sort out our buildkite setup first. Use custom checkouts #358 would simplify the many scripts quite significantly, I've just added an idea there on how to implement this change.