Adds a new pass, `splitlarge`, that recursively divides $add/$sub
cells into smaller cells until each cell's width doesn't exceed a
given max_width (128 by default.) An $add/$sub cell's width for
this purpose is defined as the higher of the widths of its two
inputs.
A test was written in Tcl for it, which tests this matrix:
- cell: $add/$sub
- b: unsigned, signed
- a: unsigned, signed
This is the first test for a Silimate pass in Tcl and thus
`run-test.sh` was modified to include it.
Calling `throw dst_end_of_data_exception()` when the desired number of cycles has been reached means that the fst reader can't tidy up after itself and leads to memory leaks.
This doesn't happen when the `-stop` flag is used because the `Yosys::FstData` struct tracks the end time and skips the outer callback if the simulation has gone past the desired end time.
Move cycle checking into the inner callback along with the time checking means that the outer callback no longer needs to throw an exception in order to stop checking further values, while still allowing the fst reader to finish reading and deallocate memory.
libfst is no longer included in gtkwave and instead has its own repo. There has also been some refactoring, so the patches need to update to match, as does sim.cc.
When building `WITH_PYTHON`, where a global list of modules is maintained, deleting a module also erases the entry in said global list. This can lead to memory corruption if the global list is destructed before the module.
Using `on_shutdown()` instead means the module destructor is explicitly called before the global list can be destructed, preventing the issue.
Also add a comment to `Pass::~Pass()` to suggest the same for future passes that might try to use that (and see this commit in the blame if they need a reason why).
Using `:=` while providing an override (either in Makefile.conf or on the command line) does not correctly apply the override in other simply expanded variables (using `:=`). Instead, passing an explicit `PYTHON_EXECUTABLE=python3.15` while leaving `PYTHON_CONFIG` implicitly defined results in it being set to `python3-config` instead of the expected `python3.15-config`.
