Use a relative path in Makefile to avoid corset executable conflicts

[gusiri]

Current issue:

I found that using CORSET ?= corset and ${CORSET} in the Makefile can be problematic. It relies on the existence of an executable named "corset" in the current working directory, which can lead to conflicts with older versions or other executables with the same name (e.g., old executable generated by cargo install --path.).

This fixes issue #143
which might be caused by ${CORSET} looking at another executable instead of ../corset/target/release/corset

---

Proposed solution:

Let's change this to a specific path ../corset/target/release/corset, similar to how it's done in prover/Makefile. This ensures the Makefile always uses the intended executable from a clear location.

For example, this will simply fix problems caused by corset executable conflicts

# instead of `CORSET ?= corset` and `${CORSET}`

define.go: ${ZKEVM_MODULES}
	../corset/target/release/corset wizard-iop -vv -P define -o $@ ${ZKEVM_MODULES}

zkevm.bin: ${ZKEVM_MODULES}
	../corset/target/release/corset compile -vv -o $@ ${ZKEVM_MODULES}

[gusiri]

CI build fails

CORSET=$HOME/corset make -B zkevm.bin
shell: /usr/bin/bash -e {0}
make: ../corset/target/release/corset: No such file or directory
make: *** [Makefile:169: zkevm.bin] Error 127

[gusiri]

Closing as Corset can be located and tested at different relative locations (e.g, CI build docker)