Update ghdl, yosys, prjtrellis, nextpnr, iverilog, scopehal-apps and ecpprog

[umarcor]

This PR updates several EDA packages at once.

I believe this is an interesting PR for triggering a corner case in CI:

MINGW64 is the only environment where all the tools can be built. Almost all of them are available on MINGW32. However, due to the order, yosys is not tested/built on MINGW32. Precisely, scopehal-apps is built before yosys, but it fails on MINGW32. Since yosys does not depend on scopehal-apps, it should be built regardless of the other one failing.

Similarly, on UCRT64, ghdl fails so all the packages scheduled after it are not tested/built.

I believe these issues are not relevant for the autobuilder, so this PR can be merged.

@Biswa96 with regard to #8956, this is a practical example of why it might be desirable to bump packages one-by-one.

[lazka]

yeah, we need to improve the CI logic...

[umarcor]

Since Python is already use in some of the CI scripts (https://github.com/msys2/MINGW-packages/tree/master/.ci), and the autobuilder is based on Python, let me suggest https://pydoit.org:

doit uses plain python to define tasks.

Task's meta-data are better described in a declarative way, but often you want to create this meta-data programmatically.

doit creates a DAG and ensures that only required tasks will be executed and in the correct order.

Traditional build-tools were created mainly to deal with compile/link process of source code. doit was designed to solve a broader range of workflows.

results from a task can be used by another task without resorting to the creation of intermediate files

So, it provides DAG management similarly to make or ninja, but it allows generating the targets/tasks programmatically: https://pydoit.org/extending.html?highlight=import#example-pre-defined-task.

[lazka]

thanks. yeah, I'll probably rewrite this in python at some point...