The build of the lexer dub subpackage requires running and building
a little config.d tool as custom pregenerate command.
Forwarding the target architecture via `--arch=$DUB_ARCH` to the
nested dub build of config.d was added in #9275, to fix cross-
compilation, but in reality broke it.
Not specifying the architecture explicitly for the little helper
build lets the compiler pick the default one, the host's native
platform in practice, which is guaranteed to be runnable on that
compiling **host**, independent from the **target** platform for
the main dub build. Suppose one cross-compiles the dmd:lexer
subpackage from x86_64 to AArch64 - an AArch64 config.d executable
will hardly run on the x86_64 host, and won't be able to generate
the `VERSION` and `SYSCONFDIR.imp` string-import files as pre-
requisite of the build.
Side note: using little separately-built .d tools/scripts as build
helpers for autogenerating little VERSION files etc. is IMO bad
practice - when cross-compiling, you require a D compiler that can
a) cross-compile, and b) build successfully for the native platform
too. Not sure this approach will e.g. ever work with GDC, where you
have different toolchains for each host->target combination.
When DMD is used as a Dub dependency and generates the DMD version as
a pre generate command. Dub will execute this command in the current
working directory, which usually is the root package working directory,
instead of the DMD package directory. This will result in the wrong
version, that is, it will pick up the git tag of the root package
instead of the DMD package.
This looks related: https://github.com/dlang/dub/pull/659.
The Dub package was unconditionally running the `config.sh` shell
script to generate the `VERSION` file. A Bash shell script will not
work on Windows. Therefore the `config.sh` script has been ported to
D, which will work on both Windows and Posix.
