feat(core.buildCommand): buildCommand DAG option

[BirdeeHub]

wrapperFunction and builderFunction were too similar.

It was the right decision to split up the resposibility of wrapping from
the rest of the logic, so they can be overridden separately, but it
could have been done much better.

What we want wrapperFunction to do, is be able to see config, and
provide a buildCommand string. They can already see the config. Why not
just let people give us strings, for builderFunction to run?

Added a buildCommand dag option.

Used it for wlib.modules.makeWrapper and wlib.modules.symlinkScript

This also gives a clear path for how to add helper modules which need to
run build commands without immediately using up all the available stdenv
hooks

wrapperFunction option still exists, however it is now declared by the
makeWrapper module, and can only return a build command string

builderFunction is now in charge of running its buildCommand argument,
which will always contain a build command string, as opposed to
processing a wrapper argument which usually but not always contains a
build command string. If you wish to pass other values to
builderFunction, you may declare it in an option, builderFunction can
see all of config still.

Also,

Added a constructFiles helper module, which is included in the default module.